[squaresmile]

I probably haven't bought into all of poetry yet but for deployment, I have been using "poetry export" to get the pinned requirements.txt, commit it to the repo and install to a virtualenv. A bit of work to keep it in sync with the poetry dependency file but that's ok.

For PATH with cron or others, I use the full path to the virtualenv such as /path/to/project/.venv/bin/python. The path can be extracted by "which" or "Get-Command" when the venv is active.

Using a python version different from the system python version is probably the messiest part but well, targeting 3.6 is alright.

I do agree it could be better and it's not quite as streamlined as other ecosystems.

[BiteCode_dev]

Honestly, pip freeze includes the whole content of a venv site-packages, and the exact versions. For most projects, that's equivalent to all the dependancies recursively pins with peotry, although you don't have the clean pyproject-dev-prod/lock file separation.

So a huge number of cases can be handled with just that. It will be "reproducible" enought for a lot of people.

[squaresmile]

> although you don't have the clean pyproject-dev-prod/lock file separation

That's why I use "poetry export -f requirements.txt > requirements.txt" instead of pip freeze. It only exports prod requirements from the poettry lock file.

[BiteCode_dev]

Nice trick, and very useful to make sure people never have to know about poetry if your team can't deal with it.