-
-
Notifications
You must be signed in to change notification settings - Fork 16
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
nco 4.7.7 has a gsl<2.3 dependency #77
Comments
To my knowledge NCO can build with any modern version of GSL, so this requirement for GSL < 2.3.0 must be somewhere in the feedstock and can/should be eliminated. |
I attempted the "Re-rendered with conda-smithy 3.1.12 and pinning 2018.10.11" workflow and it did not bump the gsl pinning in |
That is b/c the global pinning ia You can propose a new pinning in by sending a PR to that file and the bot will take care to rebuild all the dependencies in topological order. PS: at the moment the conda-forge core members are focused on the compiler migration and new pinning scheme won't be a priority. |
If I understand correctly, this isn't an issue with NCO or its conda-forge recipe but rather with the pinnings on conda-forge as a whole (https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml#L315-L316). Perhaps that's where a request to update the gsl pinning to 2.4 would need to be made. Would it make sense to close this issue and open an issue in the gsl feedstock or somewhere else instead? |
Hi @xylar, the issue with my environment is that the latest |
@akrherz, that sounds frustrating! I don't see anything in xarray's feedstock to explain the gsl=2.4 update either: Let me know if you find a working version of xarray that's compatible with nco 4.7.7. If I have time in the near future, I'll try to track down where the gsl-2.4 requirement is coming from. |
thanks @xylar , I'm gonna submit the rerender PR to see if magic happens(tm), I removed xarray and ended up hitting a conflict with h5netcdf now :( |
That is correct @xylar.
We should move that open ended |
@akrherz, for what it's worth, the following was successful for me:
Any idea what's different in what you're trying? Perhaps python 2.7? |
Ah, never mind, that's not bringing in nco 4.7.7 :-( |
@xylar I'm on python3.6 and linux 64bit. So I restored my conda install from a backup to isolate what happened and am now to this:
|
@akrherz that is b/c the latest @xylar if you force conda solver's hand you should be able to get am env with latest
not that other deps may be downgraded though to accommodate the pinning scheme. |
@ocefpaf thanks, I think for your query above, anything |
@ocefpaf and @akrherz, I think I'm running into this hdf5 version issue with the metapackage I'm trying to build. @sterlingbaldwin, I think this relates to what you just posted on E3SM-Project/e3sm-unified#26. That is, the latest nco is "ahead" of a lot of other packages on conda forge so we may just have to wait until things are in sync again... |
Done! |
@ocefpaf, I did what you suggested and here's what I see:
On the face of it, nothing odd. Perhaps I missed something. |
conda's solver is non-deterministic so by forcing |
@akrherz, could you see if you're able to create a new conda environment that meets your needs, now that we've merged #79? I'd recommend starting with a fresh environment over trying to update packages in an existing environment if at all possible because the latter is particularly non-deterministic. If you're still not having any luck, it could at least be useful to know which package(s) are causing the problem now. |
Hi @xylar, the new environment continues to fail with 4.7.7, but I believe your comment yesterday about
I realize the upgrade issue, but am lazy to rebuild my env each time I want to do upgrades. |
@akrherz, odd, I didn't have any trouble with exactly the same command as you. That was my second test when I explicitly asked for a version of nco and got a working environment without conflicts. Could this be a conda version issue? |
I'm using conda 4.5.11 |
shrug,
|
|
Different build but I don't think that explains it. |
I updated to the same build of conda as you have and still am able to create the |
@xylar do you have the |
Ah, I see. I had |
Interesting. I have |
Whelp, for whatever reason (I suspect lots of continued hard and great work by @ocefpaf) this now works, might as well close this now.
Solving environment: done
Package Planenvironment location: /opt/miniconda3/envs/test added / updated specs: The following packages will be downloaded:
The following NEW packages will be INSTALLED:
Downloading and Extracting Packages To activate this environment, use$ conda activate testTo deactivate an active environment, use$ conda deactivate |
Issue:
Current conda-forge build of nco has a gsl < 2.3.0a0 dependency, and conda-forge now has gsl=2.4
version: 4.7.7
build string: hf9e8a00_0
dependencies:
gsl >=2.2.1,<2.3.0a0
It is unclear to me if
nco
has this version requirement or not. Irregardless, installing gsl=2.4 ends up downgrading nco to 4.5.5, which then fails$ /opt/miniconda3/envs/prod/bin/ncra
/opt/miniconda3/envs/prod/bin/ncra: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
Environment (
conda list
):Details about
conda
and system (conda info
):Thank you for your excellent work on
conda-forge
, you folks are awesome!The text was updated successfully, but these errors were encountered: