Hello dynamic dependencies, my old friends #195
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Remember this and how excitedly I just chattered away in the pull request?
9b12424
Yeah, okay, about that. After blinding following one of the first guides on
pip-toolsI found years ago, I came to the understanding that there was a better way. Reading through a different write-up I saw the light. Then, like the egg I am, I took the authors advice full bait and tackle without pausing to think: "Why would I put--constraint constraints.txtin the requirements files? I just assumed this was the way. Well, here I am. Nothing but myself and the consequences of my own actions once again.Hard linking the constraint flag in the requirements files seems like a great idea. Why doesn't the
pyproject.tomlsupport that? The simple reason that I can see, after slapping my face into it at high speeds, is that you do not want to hard pin your dependencies for a library. Pretty obvious, right?So we come full circle. The
requirements*.txtfiles are just the libraries used in the package. They are dynamically linked in thepyproject.tomlso that everything builds nice and neatly. As a library package there are no pins other than the constraints of the consuming project. As a deployment artifact, maybe in a docker, the install can reference the constraints and you have controlled versions. That's the job ofnoxand just altering thebuildsession to handle a different style of building.Yes, the
devandtestoptional-dependencies should be the new dependency groups. We'll get there. Oncepip-toolssupports dependency groups (a PR is on the table now).