Packages to be moved to this repo from simit-spack

[Andrew Coughtrie (andrewcoughtrie)]

Below is a list of packages that are contained in the simit-spack repo that in theory can be moved to this repo, some may not be
worth moving and some may need some work before being moved.

Scott Wales (@ScottWales) Sam Clarke-Green (@t00sa) Yaswant Pradhan (@yaswant) Wolfgang Hayek (@tinyendian) Joerg Henrichs (@hiker) mo-marqh Harry Shepherd (@harry-shepherd) Matt Shin (@matthewrmshin) If anyone has comments or questions or concerns about any of them we can discuss here as a first point. If we all agree that starting to move them is a good idea we can open issues to do so.

• blitz
• cylc-flow
• cylc-rose
• cylc-uiserver
• fargparse
• fcm
• foxml
• gftl-shared
• gsl-lite
• hdf5
• metomi-rose
• mpich
• mule
• netcdf-c
• netcdf-fortran
• oasis
• papi
• perl-b-keywords
• perl-config-inifiles
• perl-config-tiny
• perl-critic
• perl-file-basedir
• perl-file-mimeinfo
• perl-file-which
• perl-list-someutils
• perl-module-pluggable
• perl-pod-plaintext
• perl-pod-select
• perl-pod-spell
• perl-ppi
• perl-ppix-quotelike
• perl-ppix-regexp
• perl-ppix-utilities
• perl-string-format
• perl-tidy
• pfunit
• plantuml
• py-configurable-http-proxy
• py-fparser
• py-psyclone
• py-pydata-sphinx-theme
• py-sphinx-sitemap
• py-stylist
• py-um-packing
• py-um-ppibm
• py-um-spiral-search
• py-um-sstpert
• py-um-utils
• py-um-wafccb
• rose-picker
• sci-fab
• shumlib
• vernier
• xios
• yaxt

[Yaswant Pradhan (yaswant)]

Andrew Coughtrie (@andrewcoughtrie) perhaps worth including versions we are locked into?

[Andrew Coughtrie (andrewcoughtrie)]

Each package has multiple versions, the specifying of versions is kept elsewhere but yes we will need to do that.

[Scott Wales (ScottWales)]

Sounds good to me - which of these have internal paths that you don't want to share? I see there's some in the python packages.

For the classes that are just setting up variables for the module file, can this be done in modules.yaml, e.g.

modules:
    default:
        tcl:
            all:
                environment:
                    prepend_path:
                        'CFLAGS': '-I{prefix}/include'
                        'FFLAGS': '-I{prefix}/include'
                        'CPPFLAGS': '-I{prefix}/include'
                        'LDFLAGS': '-L{prefix}/lib -Wl,-rpath={prefix}'

If not I don't think having the extra variables would hurt anything

[Andrew Coughtrie (andrewcoughtrie)]

None of the packages have internal paths that I know of, all of that is in the environment config. Things with env variables should be ok, especially as the prefix variable is a Spack one.

The only thing I think that needs to be worked out is copyright statements. Currently they are all just the default from package creation. When they go upstream they obviously need to be that, what they should be in the mean time I'm not sure.

[Andrew Coughtrie (andrewcoughtrie)]

Just read the rest of you comment rather than just the first line. As to the paths, no that doesn't work, the prepend_path setting in the modules.yaml file uses a : as the separator, there isn't any way to change that to a space which is what is needed by LFRic at the moment (not ideal I know, but it would be a reasonably complex change to the build system to change it at the moment). Some of the packages also require quite a bit of messing around to get the correct path due to the way their build system does things, pFUnit for example creates an additional subdirectory level that needs to be included in the paths.

[Scott Wales (ScottWales)]

Ah of course, yes I get you now

[Joerg Henrichs (hiker)]

Is this something Fab should support? Splitting by ":" would be reasonable simple to add, though of course if there is a ":" that's part of a path (shiver), that would be a lot more complex to handle.

[Andrew Coughtrie (andrewcoughtrie)]

Joerg Henrichs (@hiker) the LFRic requirement at the moment is in the FFLAGS, LDFLAGS and CPPFLAGS environment variables which are space separated so need a different separator that Spack can only add in certain contexts. If fab can pick up libraries and include dirs from pkgconfig (or similar) then there won't be a problem in any of this and those additions to the Spack recipes will hopefully go away.

Although technically you can have a : on a path I think anyone who does this is on their own and I wouldn't expect fab to catch it in a nice way. I can't think why fab would need to deal with separating a PATH, can you give an example where you think this may be needed?