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

Support specifying layered requirements in a single file #4331

Closed
jab opened this issue Jun 14, 2024 · 4 comments
Closed

Support specifying layered requirements in a single file #4331

jab opened this issue Jun 14, 2024 · 4 comments

Comments

@jab
Copy link

jab commented Jun 14, 2024

I recently noticed #2679 -- awesome to see all the interest in that!

As long as we're thinking about enabling combining different requirements files for different platforms into a single, platform-independent lockfile, is there any interest in enabling you to specify additional requirements layers (e.g. for running tests, building docs, etc., which should be constrained by the base layer, in a single file as well?

Many projects end up with requirements file explosion due to layering even more often than due to platform differences. Enabling users to define their requirement layers in a single file would be a wonderful simplification.

@zanieb
Copy link
Member

zanieb commented Jun 14, 2024

Hi! Have you seen PEP 735? I think that addresses what you're talking about. Right now we're only exposing a single group for development dependencies but we're watching that PEP as a possible standard we could use for specifying multiple groups. We're working on a lock file format (#3314) that is a single file. I'm not sure we'd extend locking of multiple groups to requirements.txt style files.

@jab
Copy link
Author

jab commented Jun 15, 2024

Thanks for the heads up about PEP 735, and great you're already thinking along these lines!

Any solution enabling projects to maintain a single pair of files -- one for all the dependency group inputs, and one with the result of resolving those inputs -- would be a win. Using a standardized and more structured format than requirements.txt to accomplish that would be icing on the cake.

@zanieb
Copy link
Member

zanieb commented Jun 15, 2024

Great to hear! Yeah we're planning on using the pyproject.toml for the declaration (with a tool.uv.sources extension for things like custom indexes per package that are not supported by the standard project.dependencies section) and a uv.lock with cross-platform resolutions of all of your extras and development dependencies. You can try some of it right now if you want, we'll be announcing more and writing new documentation soon though!

@zanieb
Copy link
Member

zanieb commented Jun 19, 2024

I think #3347 can be used to track this request.

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