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

Unable to install two extras in a project making use of different extras of a second library #7096

Closed
saulvargas opened this issue Sep 27, 2019 · 5 comments
Labels
auto-locked Outdated issues that have been locked by automation C: dependency resolution About choosing which dependencies to install type: support User Support

Comments

@saulvargas
Copy link

saulvargas commented Sep 27, 2019

Environment

  • pip version: 19.2.3
  • Python version: 3.6.9
  • OS: macOS Mojave 10.14.6

Description

I have a setup.py that defines extra requirements which, in turn, specify different extra requirements of a third package. My issue can be reproduced when using the following toy example:

from setuptools import setup

setup(extras_require={"extras1": "dask[diagnostics]", "extras2": "dask[delayed]"})

I am trying to install both extras at once (pip install -e .[extras1,extras2]) but, when doing so, only the requirements of the first one are actually installed (i.e. it installs dask[diagnostics], but not dask[delayed]).

I have noticed that removing these two lines allows me to do my desired behaviour.

@triage-new-issues triage-new-issues bot added the S: needs triage Issues/PRs that need to be triaged label Sep 27, 2019
@chrahunt chrahunt added C: dependency resolution About choosing which dependencies to install type: support User Support labels Sep 29, 2019
@triage-new-issues triage-new-issues bot removed the S: needs triage Issues/PRs that need to be triaged label Sep 29, 2019
@chrahunt
Copy link
Member

Thanks for the easy reproducer!

This is the same as or very closely related to #6239/#4391/#988.

@pradyunsg
Copy link
Member

Yea, this is a problem with pip's extras merging logic. We'll likely fix that with #988.

@chrahunt
Copy link
Member

chrahunt commented Oct 1, 2019

I think it would be reasonable here to make a test case and mark it xfail, then we can close this and track the fix itself with #988.

@pelson
Copy link
Contributor

pelson commented Apr 16, 2020

FWIW I just checked this against master (2f3a1be) using both the default resolver and --unstable-feature=resolver, and don't see the issue being resolved.

@uranusjr
Copy link
Member

Update from the future: The new resolver cannot solve this problem (although it’s a prerequisite) because the requirements are currently merged before it reaches the resolver, by RequirementSet.add_requirement().

The root problem is similar to #8036 (comment). I’m reopening #7571 to track this and #8036.

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label May 20, 2020
@lock lock bot locked as resolved and limited conversation to collaborators May 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation C: dependency resolution About choosing which dependencies to install type: support User Support
Projects
None yet
Development

No branches or pull requests

5 participants