Skip to content

Support for operating-system-specific requirements file #384

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

Closed
dhalperi opened this issue Nov 25, 2020 · 5 comments
Closed

Support for operating-system-specific requirements file #384

dhalperi opened this issue Nov 25, 2020 · 5 comments

Comments

@dhalperi
Copy link
Contributor

dhalperi commented Nov 25, 2020

🚀 feature request

Relevant Rules

load("@rules_python//python:pip.bzl", "pip_install")

Description

Our company uses both macOS and Linux (Ubuntu and Docker) as development / test / production platforms.

As recommended on Bazel #python Slack, we use a requirements.in file to produce requirements.txt using pip-compile. This works great, except...

The requirements.txt compilation process can be OS dependent. For example, ipython has OS_dependent deps via ':sys_platform == "darwin"': ["appnope"],.

I can't figure out how to make requirements.txt be dependent on the operating system (platform?). There's only room for one in the WORKSPACE declaration, and select statements don't work there.

Relevant thread from Slack, from @thundergolfer:

Jonathon Belotti 6 minutes ago
Ok I understand better. Yeah, in our work codebase we enforce that Linux+OSX both have the same transitively locked requirements.txt file. It's working fine in practice.
:sys_platform == "darwin"': ["appnope"] is the one place we've hit a problem.

Describe the solution you'd like

I'm not sure what the best solution is here. Can we do something in the rule to take a mapping and resolve it that way?

Describe alternatives you've considered

The main thing that seems like it would work without a rule change is a configure script that links to requirements.txt.<platform>. Seems heavyweight though.

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_python!

@github-actions github-actions bot added the Can Close? Will close in 30 days if there is no new activity label May 24, 2021
@dhalperi
Copy link
Contributor Author

touch

@github-actions github-actions bot removed the Can Close? Will close in 30 days if there is no new activity label May 25, 2021
@github-actions
Copy link

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_python!

@github-actions github-actions bot added the Can Close? Will close in 30 days if there is no new activity label Nov 22, 2021
@dhalperi
Copy link
Contributor Author

dhalperi commented Nov 22, 2021 via email

@github-actions github-actions bot removed the Can Close? Will close in 30 days if there is no new activity label Nov 23, 2021
@tsawada
Copy link

tsawada commented Feb 17, 2022

+1

alexeagle added a commit to alexeagle/rules_python that referenced this issue Apr 22, 2022
The macros are leaky and otherwise you have to read sources to find out about the kwargs

Fixes bazel-contrib#384
@mattem mattem closed this as completed in ae7a267 Apr 22, 2022
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