-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
decouple package repository from spack core #7424
Comments
We've talked about this before, and the conclusion we always reach is that Spack's core is in turmoil. Since we're still in beta mode, features are constantly being added and removed to Spack that affect how We've also talked about various ways to handle this. We could add logic to a In general, I think most Spack developers agree that this is the right long term goal. It's just a matter of whether Spack is stable enough for us to move in this direction. If you are a developer for or know any developers for other package managers with split package repositories (like Homebrew) I would love to here how they handled it and what negative consequences they encountered. |
@0xaf1f : For this reason, I have a second spack installation which is not used to install any package. I just update it all the time to get the newest versions of all packages. Whenever I think that the newer package version brings some benefit, then I go to the productive spack installation, copy away the current package (to keep the original), replace it with the newest version of the package. If this works -> keep the new package version (but don't delete the old one, such that you can always go back) So far I did not run into bigger problems with the mix&match approach. |
Thanks. It's really helpful to know someone did this. I was also considering to use a second spack download this way, but then configure it as a secondary package repository. |
Maybe ask on their mailing lists or something. I looked through the conda changelog and found this description of a new package feature and how it's handled by older versions of the package manager:
|
Ok, I've already run into an issue using
when doing various spack subcommands.
so I guess this is one of those backwards-incompatible changes to the packaging format. |
Yup, that's one of the recent additions. |
Closing this discussion as stale. Feel free to reopen if you think there's something to add. For what is worth I think #7424 (comment) still depicts the current situation very well. |
Please don't close the issue just because it's currently stale. What has changed? About other package managers / utils: So we could start by letting spack itself provide a (simulated/virtual) spack package, so that |
It would be great to be able to use the most up to date package repository without having to use the development version of the package manager itself. This was offhandedly talked about around #1325 (comment), but I'm filing it so it's not forgotten.
The text was updated successfully, but these errors were encountered: