this post was submitted on 23 Nov 2024
8 points (100.0% liked)

Python

6401 readers
12 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

πŸ“… Events

PastNovember 2023

October 2023

July 2023

August 2023

September 2023

🐍 Python project:
πŸ’“ Python Community:
✨ Python Ecosystem:
🌌 Fediverse
Communities
Projects
Feeds

founded 1 year ago
MODERATORS
 

In a requirements-*.in file, at the top of the file, are lines with -c and -r flags followed by a requirements-*.in file. Uses relative paths (ignoring URLs).

Say have docs/requirements-pip-tools.in

-r ../requirements/requirements-prod.in
-c ../requirements/requirements-pins-base.in
-c ../requirements/requirements-pins-cffi.in

...

The intent is compiling this would produce docs/requirements-pip-tool.txt

But there is confusion as to which flag to use. It's non-obvious.

constraint

Subset of requirements features. Intended to restrict package versions. Does not necessarily (might not) install the package!

Does not support:

  • editable mode (-e)

  • extras (e.g. coverage[toml])

Personal preference

  • always organize requirements files in folder(s)

  • don't prefix requirements files with requirements-, just doing it here

  • DRY principle applies; split out constraints which are shared.

you are viewing a single comment's thread
view the rest of the comments
[–] spoonbill 3 points 21 hours ago (1 children)

Constraints are useful for restricting build dependencies of your dependencies, especially if they follow PEP-518.

[–] logging_strict 1 points 2 hours ago (1 children)

Was working under the assumption that everyone considered constraints (-c) to be non-negotiable required feature.

If only have requirements (-r), in a centralized pyproject.toml, then how to tackle multiple specific dependency hell issues without causing a huge amount of interconnected clutter?

[–] spoonbill 2 points 2 hours ago (1 children)

Why do you need to have a centralized pyproject.toml?

[–] logging_strict 1 points 36 minutes ago

Within the context of resolving dependency conflicts, poetry decided pyproject.toml is a great place to put requirements.

This is what people know.

pyproject.toml or venv management should otherwise never come into the conversation.

My personal opinion is: venv, pip, pyenv, pip-tools, and tox are sufficient to manage venvs.

venvs are not required to manage requirement files. It's a convenience so dev tools are accessible.

Currently the options are: poetry or uv.

With honorable mention to pip-compile-multi, which locks dependencies.

poetry and uv manage venvs... Why?