Python Packaging, the easy way

By: Cam Wohlfeil
Published: 2019-06-25 1530 EDT
Category: Programming
Tags: python

This is an absolutely fantastic post on Hacker NEws, so much so I threw away the post I was working on for this exact same topic. All credit to the original author, I just formatted it.

Packaging, the easy way

Because I'm not on a blog, I can't go too much into details, and I'm sorry about that. It would be better to take more time on each point, but use them as starting point. I'll assume you know what virtualenv and pip. If you don't, check a tutorial on them first, it's important.

But I'm going to go beyond packaging, because it will make your life much easier. If you want to skip context, just go to the short setup.cfg section.

Calling Python

Lots of tutorials tell you to use the python command. But in reality, often several versions of Python are installed, or worst, the python command is not available.

WINDOWS

If the python command is not available, uninstall Python, and install it back again (using the official installer), but this time making sure that the Add Python to PATH box is ticked. Or add the directory containing python.exe, and its sibling Scripts directory to the OS system PATH manually (check a tutorial on that). Restart the console.

Also, unrelated, but use a better console. cmd.exe sucks. cmder (https://cmder.net/) is a nice alternative.

Note from Cam: I like PowerShell and the new (beta) Windows terminal!

Then, don't use the Python command on Windows. Use the py -x.y command. It will let you choose which version of Python you call. So py -2.7 calls python 2.7 (if installed) and py -3.6 calls Python 3.6. Every time you see a tutorial on Python telling you to do python this, replace it mentally with py -x.y.

UNIXES (mac, linux, etc)

Python is suffixed. Don't just call python. Call pythonX.Y. E.G: python2.7 to run python 2.7 and python3.6 to run Python 3.6. Every time you see a tutorial on Python tell you to do python this, replace it mentally with pythonX.Y. Not PythonX. Not python2 or python3. Insist on being precise: python2.7 or python3.5.

LINUX

pip and virtualenv are often NOT installed with Python, because of packaging policies. Install it with your package manager for each version of Python. E.G: yum install python3.6-pip or apt install python3.6-venv.

FINALLY, FOR ANY OS

Use -m. Don't call pip, but python -m pip. Don't call venv, but python -m venv. Don't call poetry but python -m poetry. Which, if you follow the previous advices, will lead to things like python3.6 -m pip or py -3.6 -m pip. Replace it mentally in tutorials, including this one.

This will solve all PATH problems (no .bashrc or windows PATH fiddling :)) and will force you to tell which python version you use it with. It's a good thing.

In any case, use a virtualenv as soon as you can. Use virtualenv for everything. One per project. One for testing. One for fun. They are cheap. Abuse them.

In the virtualenv you can discard all the above advices: you can call python without any py -xy or suffixes, and you can call pip or poetry without -m. Because the PATH is set correctly, and the default version of Python is the one you want.

But there are some tools you will first install outside of venv, such as pew, poetry, etc. For those, use -m AND --user. E.G:

This solves PATH problems, python version problems, doesn't require admin rights and avoid messing with system packages. Do NOT use sudo pip or sudo easy_install.

Using requirements.txt

You know the pip install stuff, pip freeze > requirements.txt, pip install -r requirements.txt ?

It's fine. Don't be ashamed of it. It works, it's easy.

I still use it when I want to make a quick prototype, or just a script.

As a bonus, you can bundle a script and all it's dependencies with a tool named pex:

pex . -r requirements.txt -o resulting_bundle.pex --python pythonX.Y -c your_script.py -f dist --disable-cache

It's awesome, and allows you to use as many 3rd party dependencies as you want in quick script. Pex it, send it, python resulting_bundle.pex and it runs :)

Using Setup.cfg

At some point you may want to package your script, and distribute it to the world. Or maybe just make it pip installable from your git repo.

Let's say you have this layout for your project:

root_project_dir/
├── your_package
├── README.md

Turn it into:

root_project_dir/
├── your_package
├── README.md
├── setup.cfg
├── setup.py

And you are done. setup.py needs only one line, it's basically just a way to call setuptools to do the job (it replaces the poetry or pipenv command in a way):

from setuptools import setup; setup()

Setup.cfg will contain the metadata of your package (like a package.json or a pyproject.toml file):

[metadata]
name = your_package
version = attr: your_package.__version__
description = What does it do ?
long_description = file: README.md
long_description_content_type = text/md
author = You
author_email = foo@bar.com
url = https://stuff.com
classifiers = # not mandatory but the full list is here: https://pypi.org/pypi?%3Aaction=list_classifiers
    Intended Audience :: Developers
    License :: OSI Approved :: MIT License
    Programming Language :: Python :: 3.5
    Programming Language :: Python :: 3.6
    Programming Language :: Python :: 3.7
    Topic :: Software Development :: Libraries

[options]
packages = your_package
install_requires =
    requests>=0.13 # or whatever

[options.package_data]
* = *.txt, *.rst
hello = *.msg

[options.extras_require]
dev = pytest; jupyter # stuff you use for dev

[options.package_data] # non python file you want to include
* = *.jpg

You can find all the fields available in the setup.cfg here. Setup.cfg has been supported for 2 years now. It's supported by pip, tox, all the legacy infrastructures.

Now, during dev you can do: pip install -e root_project_dir. This will install your package, but the -e option will make it work in dev mode, which allow you to import it, and see modifications you did to the code without reinstalling it every time. setup.py develop works too.

If you publish it on github, you can now install your package doing:

pip install git+https://github.com/path/to/git/repo.git

You can also create a wheel out of it doing:

python setup.py bdist_wheel

The wheel will be in the dist dir. Anybody can then pip install your_package.whl to install it. Mail it, upload it on an ftp, slack it...

If you want to upload it on pypi, create an account on the site, then pip install twine so you can do:

twine upload dist/*

Read the twine doc though, it's worth it. You could use python setup.py bdist_wheel upload instead of twine. It will work, but it's deprecated.

Using pew

Pew is an alternative to venv, poetry, virtualenvwrapper and pipenv. It does very little.

`pew new env_name --python python3.X`

Creates the virtualenv.

`pew workon env_name`

Activates it. And optionally moves you to a directory of your choice. That's all. It's just a way to make managing virtualenv easier. Use pip as usual.

You can know where your virtualenv has been created by looking up the $VIRTUAL_ENV var.

This is especially useful for configuring your IDE, although I tend to just type which python on unix, and where python on Windows.

Using poetry

Now, if you need more reliability, poetry enters the game. Poetry will manage the virtualenv for you, will install packages in it automatically, will check all dependencies in a fast and reliable way (better than pip), creates a lock file AND update your package metadata file.

I'm not going to enter into details on how this work, it's a great tool, with a good doc.

You don't need to start with poetry. You can always migrate to it later. Most of my projects do the requirements.txt => setup.cfg migration at some point. Some of them move to poetry if I need the extra professionalism it provides.

The problem with poetry is that it's only compatible with poetry. It uses the pyproject.toml format, which is supposedly standard now, but is unfinished. Because of this, any tool using it, including poetry, actually stores most data in custom proprietary fields in the file :( Also, it's not compatible with setuptools, which many infrastructures and tutorials assume. So you'll have to adapt to it.

That being said, it's a serious and robust tool.

Compile to Binary

If you want to compile Python to an exe, use nuitka, not p2exe, cx_freeze and co.

Further Reading