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 ?

Hi,

• 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

Makefile

to document/manage a

constraints.txt

file referenced from

pants.toml

as:

# pants.toml
[python]
# Use poetry export to regenerate this lockfile.
requirement_constraints = "constraints.txt"

# 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...

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 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

resolve=<name>

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)