-
Notifications
You must be signed in to change notification settings - Fork 7
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
Customizing Your DESI Python Environment #38
Comments
Right. The desiconda version has not been updated in so long that some of the package versions used are no longer available from the upstream repositories. The desiconda install should be updated, or you can copy the package list and remove those lines containing packages that were not found. These are all low-level packages and the correct versions should be pulled in by the higher level packages in the list. |
Indeed I am able to proceed after removing the above packages from the list. Thanks Ted. |
Our desiconda installation is less than a year old (August 2019), which isn't a good sign about the shelf life of our software releases and instructions for how users can spawn their own custom environments from them. When installing desiconda, presumably the now-missing packages were downloaded. Is there any option to cache them so that they remain on disk in a place that new user environments could pick them up even if they aren't available from anaconda/condaforge anymore? I'd like to make a new desiconda installation "soon" to update fitsio and astropy and remove jupyter lab stuff, so if there is some way we can do that to enable the next release to last longer than 6 months that would be helpful.
Containers is another solution for long term reproducibility, but that brings in other overhead for users. I'm inclined to use those for big data releases, but not for daily use of software releases that are less than a year old. |
We could fairly easily install a different package list that included only our "core" high-level dependencies with versions (numpy, astropy, etc). And then just let conda figure out the low-level dependencies. That should probably be fine for creating new environments up to ~1 year later. I think that the only way to support running very old stacks is to have everything in a container. |
A very similar problem was recently reported on the DESI Trac ticket system. Did this ever get resolved? I seem to recall discussion of this more recently than March, perhaps on the desi-data mailing list. |
PS, the ticket on Trac involved a very old version of desiconda, but that still leaves open the question of whether there was a formal resolution to this issue. |
I am following the instructions at https://desi.lbl.gov/trac/wiki/Pipeline/GettingStarted/NERSC#CustomizingYourDESIPythonEnvironment. I am running into an error here with regards to PackagesNotFound.
(base) akim@cori04:~> conda create -p ${HOME}/mydesi --copy --file ${DESICONDA}/pkg_list.txt
Collecting package metadata (current_repodata.json): done
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: failed
PackagesNotFoundError: The following packages are not available from current channels:
Current channels:
To search for alternate channels that may provide the conda package you're
looking for, navigate to
and use the search bar at the top of the page.
The text was updated successfully, but these errors were encountered: