Skip to content
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

Problems with Python 3.9.* - umap-learn<0.4.0 needed? #102

Open
LustigePerson opened this issue Jul 12, 2021 · 3 comments
Open

Problems with Python 3.9.* - umap-learn<0.4.0 needed? #102

LustigePerson opened this issue Jul 12, 2021 · 3 comments

Comments

@LustigePerson
Copy link

First of all,

thanks for this great project. I tried to use scanpy-scripts in a python 3.9 environment but could not install it.
Neither with pip nor with conda.

The problem seems to come down to umap-learn in the requested version <0.4.0.

As far as I can see the the also requested scanpyversion (>1.8.0) ist not restrictign umap-learn anymore.
Is there any specific reason to keep the version before 0.4.0?

Repro-Scenario

I used the miniforge3 docker container:

docker run -it condaforge/miniforge3 bash
conda create  -n scanpy_scripts -d -c bioconda scanpy-scripts python=3.9

This results in an UnsatisfiableError, which seems to be caused by umap-learn<0.4.0, as this is the only of the requested packages that I can not install manually (see below),

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: -
Found conflicts! Looking for incompatible packages.                                                                                  failed

UnsatisfiableError: The following specifications were found to be incompatible with each other:

Output in format: Requested package -> Available versions

Package python conflicts for:
scanpy-scripts -> anndata -> python[version='2.7.*|3.5.*|>=3.5|>=3.7,<3.8.0a0|>=3.6,<3.7.0a0|>=3.9,<3.10.0a0|>=3.8,<3.9.0a0|3.4.*|>=2.7,<2.8.0a0|>=3.5,<3.6.0a0|>=2.7|>=3.7']
python=3.9
scanpy-scripts -> python[version='3.6.*|>=3.6|>=3']
>> conda create  -n scanpy_scripts -d -c bioconda "umap-learn<0.4.0" python=3.9
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: \
Found conflicts! Looking for incompatible packages.                                                                                  failed

UnsatisfiableError: The following specifications were found to be incompatible with each other:

Output in format: Requested package -> Available versions

Package python conflicts for:
python=3.9
umap-learn[version='<0.4.0'] -> numba[version='>=0.35'] -> python[version='3.4.*|>=3.9,<3.10.0a0']
umap-learn[version='<0.4.0'] -> python[version='2.7.*|3.5.*|3.6.*|>=2.7,<2.8.0a0|>=3.6,<3.7.0a0|>=3.8,<3.9.0a0|>=3.7,<3.8.0a0|>=3.5,<3.6.0a0']

So the question is, does umap-learn has to be fixed or is the problem coming from some other package?
FYI: I already udpated the conda-receipt to match the current requirements: PR 29511

@pinin4fjords
Copy link
Member

Thanks for tidying up the Biconda recipe @LustigePerson , I meant to intercept the auto-PR in Bioconda to make those changes, but obviously it slipped my mind!

The umap-learn pin was updated to deal with #81, but I'm trying in the above-noted PR to unpin it. If the CI passes I have no issue with that.

@pcm32
Copy link
Member

pcm32 commented Jul 12, 2021

I think that moving the Scanpy version below without changing the scanpy-scripts version (but only the build) will break some calls that break from 1.7.x to 1.8.0, we need to revert this in bioconda and only merge those changes on a new version of scanpy scripts, so that 0.4.x keeps pointing to 1.7.x. This will also generate a new version of the container with an important change in scanpy but without signalling it on the version, which can break some galaxy tools that make use of the 1.7.x calls.

@pcm32
Copy link
Member

pcm32 commented Jul 12, 2021

All good, and thanks for the fix @LustigePerson, I was under the impression that the 1.0.0 release of this package hadn't happened yet, but that release had already moved to scanpy 1.8.0, so all good!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants