Wrong build of mpich selected with metapackage #924
Labels
Comments
|
Also note is that the bad solve gives an old version of gfortran (7.5.0 instead of 9.3.0), further evidence that it is related to #848 . |
|
Also note that the solution is odd because the mpich external package has an extra feature compared to the normal mpich ones. |
|
Hi, yeah our handling of the "track-features" de-prioritiziation is not ideal yet... Basically conda has an optimisation routine where it tries hard to not use any packages that have "track-features". Mamba / libsolv is not so strict about that as of now. We'll have to see how we could integrate that in a stricter way into libsolv -- maybe completely filtering any package that has a track_feature unless explicitly requested or something like that. |
|
I've recently been working on this in openSUSE/libsolv#448 Will be interesting to see if this is fixed. |
|
@ktlim can you check if this solution looks decent to you? |
|
That looks better! |
|
I see various other build differences between the list above and what conda returns. I'm guessing that conda sorts by date, taking the latest build, while mamba might not? In addition, there are some actual version differences that may indicate other problems (or might indicate equal-weight solutions?): |
|
@ktlim the decorator restrictions come from networkx 2.5.1 and are probably more correct: https://github.com/conda-forge/networkx-feedstock/blob/master/recipe/meta.yaml The networkx 2.5 build should probably be patched / removed. Similarly for sphinx: you can see how sphinx 3.5.3 depends on docutils>0.14, and the 3.5.4 version has a constraint for docutils>0.14,<0.17. So it remains a very hard problem to choose the "better" solution. |
adriendelsalle
added
the
status::need-triage
adriendelsalle
added
type::bug
|
A new day a new try :) Does someone have a minute to take a look at this package resolution? |
|
mpich looks fine - @ktlim will have to inspect the rest What is done differently here from last time in the solver? |
|
I've uploaded a new build of libsolv. It should fix this behavior :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have a metapackage named
rubin-envthat includesmpich =3as a dependency.mamba create -n myenv rubin-env=0.5.0is installing mpich=3.4.1=external_4. This causes failures because there is no other MPI installed on the system.conda create -n myenv rubin-env=0.5.0correctly installs mpich=3.4.1=h846660c_104.If I create a YAML file
re.yamlbased on the dependencies in therubinenv-feedstock/recipe/meta.yaml, things work properly:mamba env create -n myenv -f re.yamlcorrectly installs mpich=3.4.1=h846660c_104.The metapackage environment creation problem occurs even if the proper package has already been downloaded by creating the YAML-based environment.
mamba create -n myenv rubin-env=0.5.0 mpichormamba create -n myenv rubin-env=0.5.0 scipyormamba create -n myenv rubin-env=0.5.0 libgfortran5all seem to work properly. That suggests that this may be related to #848.It may or may not be related that the
mpich-3.4.1-external_4.jsonfile in the environment'sconda-metadirectory has"track_features": "",whileconda search -i mpich=3.4.1=external_4showstrack_features: - mpich_external.@beckermr and @erykoff have been looking at this with me.
The text was updated successfully, but these errors were encountered: