heya i got a question regarding poetry and lockfil...
# general
heya i got a question regarding poetry and lockfiles. I've been trying to make sense of all the issues regarding this topic but I'm confused: • is it currently possible to respect poetry.lock ? • is it currently possible to have a poetry.lock for each project in the repo? • if not: is any of that planned/on the horizon ?
• is it currently possible to respect poetry.lock ?
I’ll share what I have in a project where we use poetry and pyproject.toml for managing 3rdparty dependencies. Alas, it’s one global, not per project. I’ve a
to document/manage a
file referenced from
Copy code
# pants.toml
# Use poetry export to regenerate this lockfile.
requirement_constraints = "constraints.txt"
Copy code
# Makefile
constraints.txt: poetry.lock
	poetry export --without-hashes > $@

poetry.lock: pyproject.toml
	poetry lock --no-update && touch $@
• is it currently possible to have a poetry.lock for each project in the repo?
I’ll let the others fill in the blanks here wrgt multiple lockfiles and what the support for that looks like at the moment.
Pinging @hundreds-father-404 re multiple lockfiles...
btw Eric is on vacation for a couple days, so don't be alarmed if you don't hear from Eric until Friday. @happy-kitchen-89482 is there anyone else available meantime who could discuss the status of adding support for multiple lockfiles?
Hey @polite-secretary-23285, for clarification - what would be the reason to have separate poetry.lock files per project? I ask because one idiomatic way to work with Pants is to have one consistent global resolve and let Pants itself decide which subsets of requirements are needed in each scenario. Reasons why you might need multiple resolves include the need for conflicting dependencies in different parts of the codebase, or the need to use legacy tooling that expects a per-project resolve (although in this case you can have Pants generate one for you). So I'm curious about your use-case?
"I just prefer it that way" is also a perfectly fine answer!
"i prefer it that way" is part of it. our python developers are used to working with poetry, and maintaining a lock-file for each project within the mono-repo. if possible i want to keep the adoptation-friction as low as possible
"I want to keep the adoption-friction as low as possible" is always a solid reason around here.
Makes sense. So how do you keep the lockfiles in sync with each other today, so that they don't conflict? Or do you just not do that, and they're allowed to conflict, since each one represents a separate project? And, related question: Do you have library code in your repo that is shared across the projects?
is it currently possible to respect poetry.lock ?
No, the closest you can get is using
poetry export
so that pex (and thus pip) can understand it. Indeed, what Andreas shared
is it currently possible to have a poetry.lock for each project in the repo?
Yes, this is possible in Pants 2.10.0rc1. Docs are still a WIP, but this option is how you'd do it: https://www.pantsbuild.org/v2.10/docs/reference-python#section-resolves. You would need to
poetry export
each project, then set it up as a distinct resolve. You'd also need to update all targets for that project to set the field
Note that you could use
./pants generate-lockfiles
to generate the lockfiles. In Pants 2.10, we use Poetry to generate the lockfile, we literally run
poetry lock && poetry export
for you. (That will change in Pants 2.11)
I'm happy to give more detailed instructions if you have questions 🙂 We're very interested in both helping you out here + getting feedback on the new