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

pip-compile not propagating platform_system #1676

Closed
jamesbraza opened this issue Aug 24, 2022 · 5 comments
Closed

pip-compile not propagating platform_system #1676

jamesbraza opened this issue Aug 24, 2022 · 5 comments

Comments

@jamesbraza
Copy link

Environment Versions

  1. OS Type: macOS Big Sur v11.5.1
  2. Python version: $ python -V: 3.10.3
  3. pip version: $ pip --version: 22.2.2
  4. pip-tools version: $ pip-compile --version: 6.8.0

Steps to replicate

I have a PEP 508 dependency specification present platform_system:

requirements.in

windows-curses ; platform_system=="Windows"

Then running:

pip-compile --upgrade --annotation-style=line --no-emit-index-url --no-header

Expected result

windows-curses==2.3.0 ; platform_system=="Windows"  # via -r requirements.in

Actual result

(the windows-curses field is not propagated)

How can I get it to be propagated?

@AndydeCleyre
Copy link
Contributor

(the windows-curses field is not propagated)

You mean the platform_system environment marker?

@AndydeCleyre
Copy link
Contributor

Oh I see. Yes, when you run pip-compile on a platform for which an environment marker evaluates as false, the corresponding requirement is not part of the resulting locked dependency tree, and this is currently expected behavior.

You may be interested in the discussion at #1326.

@AndydeCleyre
Copy link
Contributor

Does it work for you to close this, to funnel relevant ideas into #1326?

@jamesbraza
Copy link
Author

Sure, I am down to redirect ideas into #1326! I don't have any ideas of a solution, just more raising the feature request.

It may be helpful for other users searching through issues to notice this is open, and close it out when #1326 is implemented. However, if you want to close this out now, please feel free 🙂

@AndydeCleyre
Copy link
Contributor

Oh, #826 is more directly relevant, but I also wonder about merging that issue into #1326. It's not obvious how to move forward on these issues, so it's not about to get implemented. We need to establish a clear and sane strategy.

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

2 participants