-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Difficulties installing other packages into the isis3
conda environment
#615
Comments
Relaxing the Anaconda dependencies may resolve this problem. That is both a big challenge and may not actually fix the problem because of difference between how gdal and isis3 are compiled. Anaconda doesn't do a good job differentiating between different builds and compilation environments. For example, many of the ISIS3 dependencies are pinned to specific builds and labels on conda-forge because they have to be compiled with gcc 5+ for binary compatibility (this is why CentOS7 has its own environment). Substituting these for different builds that used gcc 4 would cause linking errors. We are hoping to go to more standardized builds and getting everything onto conda-forge, but there is no guarantee that would be enough to prevent the clash with gdal. |
For the moment I see two solutions: The PATH editing solution
This basically adds the ISIS3 binaries to your path and then adds the gdal environment on top of it. You could do some creative activate.d and deactivate.d editing to automate this whenever you activate the gdal environment. The manual build solution
This will manually install the ISIS3 binaries, preference file, xmls, etc. into your gdal environment. This way, when you activate your gdal environment, the ISIS3 binaries will already be in your PATH and ready to go. |
I really don't find the PATH manipulation solution too bad. But maybe we should provide some well working scripted solutions for likely scenarios. And, I'm still trying to figure out how to make things working on the fish shell, b/c the activation scripts are not being read by fish. Currently creating an conda GH issue about it, b/c they support fish in general. |
This is problem for me also, but perhaps an opportunity to enhance both GDAL and ISIS3. So during an ISIS3 build, is a conda env used? If so, can't we first create an env with existing versions of GDAL (and Python, AstroPy, PVL, SpiceyPy, Pysis, etc.) which will set an existing (and available) environment for those binaries. Now build ISIS3 based on those environments...? This feels like being as locked down as a statically built binary but at least it will allow for some related binaries to be available within an ISIS3 environment. This also would have the benefit our GDAL (HiRISE) users to be able to run GDAL tools against the ISIS3-delivered Kakadu library (for Jpeg2000 support).
Anyway, for a current workaround, I have a conda env for isis3 and different env for gdal (which has all the Python stuff like PVL, mathplotlib, scipy, ect.). I have tested a single script (bash) which, runs some isis3 stuff, activates gdal, runs gdal stuff, and back to isis3
|
@thareUSGS Your proposed build a big environment is roughly equivalent to just installing ISIS3 into the environment. |
@thareUSGS I also think most of those dependencies could be changed, possible excluding geos. ISIS is still using a relatively custom geos build. |
@jessemapel Yes - but we would preemptively do this as "nicety" for the users, since it is something we can control from here. |
Adding to this because I experienced a similar problem, and didn't see the package I was unable to add to the isis3 environment already listed on this ticket: I needed to set up a separate conda environment to use matplotlib, so I have one conda env for isis3 and then another for "default python" including matplotlib. Looking at this issue again, this is actually almost exactly much the same thing that Trent said above about having separate python and isis3 environments, so never mind! |
Interestingly, matplotlib installs while "only" downgrading isis3 from 3.6.0-py36_3 to 3.6.0-py36_0. But, due to a recent conda "feature" from the devil called "features" it mixes packages from the defaults channel with conda-forge channels. This can lead to unpredictable errors and I strongly recommend when working with the conda-forge channel to pin numpy and gdal to conda-forge so that no default channel packages are being mixed in that are available on conda-forge, like so:
After doing that, this is the suggestion that conda offers for matplotlib into isis3:
|
Hah, and I just realized that the same should be done for
the changes are actually minor and isis3 is NOT being downgraded at all!
EDIT: Sorry for the accidental closing. @kberryUSGS , this should be a safe way to add matplotlib to the |
Motivated by this success I tried adding my standard science stack, and, alas apart from GDAL and geopandas, all these work!
with the only change of existing package: The following packages will be UPDATED:
tbb: 4.4-hf7780a4_0 usgs-astrogeology --> 2019.2-h2d50403_0 conda-forge Would be interesting to know if that would break |
@michaelaye I don't remember why we're serving that library at the moment. Maybe I'll test updating that to conda-forge's build tomorrow. |
@jessemapel @michaelaye Is this a good opportunity to get an issue open, labelled as 'good for beginner' (maybe?), and then solicit to have some community members do some experimentation with this. I agree 100% that being able to get the scientific Python stack and GDAL into the ISIS3 env would be very powerful. We know we want to be off as many snowflake builds as possible. I do not see us getting back onto the track of addressing this until, optimistically, sometime in the new year. Not a cop out, but not cycling back to our maintenance project for a while. |
@jlaura That sounds good to me. I was going to mark this as will not fix because getting GDAL working with ISIS dependencies could be a serious problem. |
I'm going to close this issue. We're doing some work on this under #648 but it probably make ISIS work with everything. |
I'm reactivating this thread, not because I have a solution to the underlying problem, but because following some discussions today, I have written up some instructions for how to carry out the steps to have ISIS in one environment, but referenced from another. Where should I PR these instructions, on the main README in the Installation section? Somewhere else? |
I think into the README is reasonable for now. Maybe as an advanced option in the Installation section? We are hoping to have some funding next FY to work on our documentation in general, so it is likely to move around then no matter where it goes now. |
I guess in the long run we might want |
The current strict requirements table leads to difficulties for conda to resolve the dependency tree when trying to install anything on top of the
isis3
environment.For example (h/t to @rbeyer ):
the conda requirement resolution leads to the suggestion to remove the
isis3
package.This is most likely caused by the strict requirements instruction of the
isis3
package:How could this be addressed?
The text was updated successfully, but these errors were encountered: