Move spack-stack repos to builtin repo within Spack

[kgerheiser]

I think we should combine our repos into a single. We only have about a dozen packages and I think it just makes it more confusing to find if a package is in common/ufs/jedi. Spack has several thousand in the builtin repo, I think we're fine with just a handful.

My proposal is to have two repos: spack-stack and bundles. All the bundle envs we have go in bundle and all the regular packages go in spack-stack.

[climbfuji]

For my understanding, are you suggesting to have those repos inside the spack submodule in var/spack/repos/... ? That's needed if we want to build containers that contain any of these packages.

[edwardhartnett]

I don't understand what you are proposing here - can you elaborate further?

[climbfuji]

I don't understand what you are proposing here - can you elaborate further?

If we want to build containers that have some of our software packages (which are not or not yet in the official spack repository), then we need to move them into the repos folder in our spack branch. The spack container build relies on a branch of spack itself from where it obtains all packages. Right now, "our" packages that are not/not yet in the official spack repository are stored in subdirectories configs/repos/... of this spack-stack repository, not inside our spack branch (which is a submodule of spack-stack).

[kgerheiser]

My proposal was to put them in a single package folder within spack-stack instead of having like 2 in each folder. But now that you say it, moving them to the builtin repo is probably a better idea.

[kgerheiser]

One thing I don't like is adding the bundle packages to the builtin repo since they aren't real packages, and I think it would be nice to keep them separate just for clarity. What if we add a custom repo in our Spack fork alongside builtin like bundles? That way it's available to Spack internally and we get to keep them separate.

Also, there's a duplicate package named atlas for linear algebra that conflicts with ECMWF Atlas. Not sure on the best way to handle that. Maybe re-name it EcmwfAtlas and provide a projection to change its name?

[climbfuji]

One thing I don't like is adding the bundle packages to the builtin repo since they aren't real packages, and I think it would be nice to keep them separate just for clarity. What if we add a custom repo in our Spack fork alongside builtin like bundles? That way it's available to Spack internally and we get to keep them separate.

I fully agree that the bundles don't belong in there and I like that idea to separate them in another directory.

Also, there's a duplicate package named atlas for linear algebra that conflicts with ECMWF Atlas. Not sure on the best way to handle that. Maybe re-name it EcmwfAtlas and provide a projection to change its name?

Good point about atlas. We can rename it to ecmwf-atlas and use a projection as you suggested.