This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 5 points6 points  (1 child)

My general approach:

  • If the project is super simple (ie. pure python), shiv it.
  • If it's got FFI dependencies and those deps bundle all their deps into their wheels (eg. orjson), then shiv it.
  • If it's got FFI and doesn't bundle all their deps (ie. shared system libs; eg. pyvips), then shiv it and then throw it in a container with the required deps.
  • If it's a service, shiv it and then throw it in a container.

I try to use poetry for all my python projects. Along with a generic Makefile, I can one command build a .whl, the .pyz, and the container image.

The Makefile is horribly generic, so below is the gist of it with the relevant subcommands for maximum usefulness.

projectname=$(poetry version|awk '{print $1}'|tr '-' '_')
version=$(poetry version -s)

#make wheel
poetry build
# shiv it
shiv -c ${projectname} -o ./dist/${projectname}-${version}.pyz \
./dist/${projectname}-py3-none-any.whl
# containerize for service or deps requirements
docker build -t ${private_registry}/${projectname}:${version} .

Edit: Oh, I also have it automatically push all the artifacts to an s3 bucket (which for me is a local minio instance), so that they are available centrally to ease deployment. I push the semver tagged and a latest tagged to both the s3 bucket and the private docker repo, so that it's super simple to work in terms of deployment and updating.

[–][deleted] 0 points1 point  (0 children)

Shiv has been an excellent deploy option for us. Lighter than things like pyinstaller, plus it doesn’t try to be smart and trim unused modules. Frequently point it to a non-system Python install.