Poetry: Feature Request: poetry deploy

[bertjwregeer]

• [x] I have searched the issues of this repo and believe that this is not a duplicate.

poetry deploy

What I am looking for is a way to generate a poetry.lock and my project wheel and then deploy them without needing to have any of the source/pyproject.tom or anything else available. Preferably into a venv of my choosing, or a default created one.

Running poetry build with a --with-lock that copies the existing poetry.lock, renames it to be versioned and adds the hash for the newly built wheel, and then places that in the dist folder.

Then when a user wants to deploy, they specifically do:

poetry deploy myapp-0.1.0-poetry.lock

And poetry would create a new virtualenv (or update it) and installs the application with the locked dependencies, verifying the wheel file (which has to exist in the same folder as the lock file, or maybe add a --wheel-path to allow an alternate location to find wheels, default to next to .lock fall back to PyPI).

Either way, the end result should be a virtualenv that has all of the dependencies + package installed as set in the lock file without needing to have the source code available.

This would be great for doing deployments inside of Docker containers, or Heroku build-packs so that you don't need to ship the full source, just the lock file and a wheel.

[mmerickel]

I think poetry build --lock is a really interesting way to do it. This would just snapshot the pinned dependency set into the wheel instead of the loosely pinned constraints in pyproject.toml. Then I use that wheel with any other tool (probably pip) in deployment to install my app.

$ poetry build --lock
$ python3 -m venv env
$ env/bin/pip install --find-links=dist myapp

The alternative is to just use poetry build to get a loosely constrained wheel, and some other endpoint like poetry build --export-requirements-file requirements.txt that dumps out a file of locked deps. This would be something along the lines of https://github.com/sdispater/poetry/issues/100.

$ poetry build --export-requirements-file requirements.txt
$ python3 -m venv env
$ env/bin/pip install --find-links=dist -r requirements.txt myapp

[hynek]

The lack of something like this is pretty much the only reason I cannot put poetry into production.

As of now, if you're in an activated virtualenv and call poetry install, it does exactly what you want to.

However it's impossible to pass it as a parameter or env variable which is a problem on build servers.

A cheap win would be something like TARGET_VENV=/app poetry install but I understand that that's rather clunky, especially in the context of the whole design.

I kinda like the idea of poetry deploy but I’d rather call it poetry bundle or something like that and make it pluggable. Imagine being able to call: poetry bundle --type venv /app or poetry bundle --type shiv Fooo.shiv or even poetry bundle --type pyinstaller Foo.exe – what do I know. There's many ways to bundle a Python application.

---

P.S. requirements.txt exports are a thing as of #675 but since I’d want to go all-in on poetry it means I have not setup.py so it doesn't help me when deploying.

[rajeev]

Just a note: I'm working on something similar to this on #799

[hangtwenty]

I do like the options discussed above and option #799, so I'm excited to see where this goes... In the meantime if people need workarounds, these may be worth considering as a shim/holdover:

for holdover -

• https://github.com/wolever/pip2pi
• https://github.com/raphaelcohn/swaddle
• https://pypi.org/project/Wheelhouse/

maybe relevant to #799 if there is work left to be done in there and you are looking for inspiration (I haven't reviewed it, just spitballing!)

• https://github.com/Miserlou/Zappa#how-zappa-makes-packages -- even though Zappa is specific to certain web frameworks and AWS Lambda, code or patterns could be reused from it

[shimil]

Any news on this?
Did anyone find a better way to do this?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[merwok]

Still an important feature request!

[sdispater]

The bundle command mentioned by @hynek is definitely on my radar but will likely be implemented after the 1.0 release.

[gsemet]

I also like the plugin mecanism that would allow to do poetry bundle --type pyinstaller myapp.exe, poetry bundle --type pynsist appinstaller.exe, ...

[lig]

At least, it would be handy now to have a documented way to reproduce an environment which will guarantee the following:

• poetry.lock exists
• poetry.lock is up to date with pyproject.toml
• The environment was created from poetry.lock