Current State of Python Packaging

I don't have a problem with the command line, I just find the argument of "tool X and tool Y are boring to use so you'd better tool Z" (as found on the linked article) a bit weak. I guess that's one of these tools that solves problems I don't have (like the need for a lock file... just specify the version in requirements.txt), so unless it becomes the new standard, I'll stay away from it. But I'm sure it's gonna be helpful for many.

Yes, it's still very valid. It's simple. It's baked in.

However, the benefit of moving to setup.cfg (not setup.py anymore, which should be almost empty) is more than making a lib. It makes deployment easier, and dev as well. Hell, you can even pip install from git repo with it.

I made a summary of what to use for what, when and how in this comment: https://news.ycombinator.com/item?id=20132303

Indeed.. I stopped writing libraries when I switched to Python, because for all my needs there are better ones out there than those I could write. Only write apps now... :)

From the little development I have done in Rust, I have to agree.

On the other hand, I’ve been working with react-Native and typescript recently, and it’s a constant mess. Every invocation of yarn leaves at least a couple of warning messages about things that are out of my control. Installing packages is slow and at least every few days I have to wipe out node_modules and nuke any iOS build folders in order to get it working again. That said, RN is promising technology and hopefully my frustrations are due to more inexperience than the tools or language and ecosystem. I just wish all of the JavaScript stuff were faster. I’m on a gigabit connection and fast hardware but still it seems sometimes yarn has to download or unpack 6500 files or something

We are making a Cargo-like build toolchain for C/C++, if anyone is interested: https://build2.org

Nope. Absolutely not. Cargo makes the simple things easy but is less thought out than Rust itself.

From the click user point of view, yeah.

From the dev user or packager point of view, no.

First, there is no namespace in JS. Secondly, the import instruction standard is not implemented everywhere, so we need a bundler. First, the network makes everything harder. And finally, JS has virtually no stdlib.

Add to that that we we are stuck in npm land, with acute lefpadite, packages breaking the public API every sunday, and a mad hatter packager like webpack as our lord and savior, and you have a recipe for terrible times.

May I know if you package 3rd party dlls in your flask app, does it run on *nix platform?

Yes I'm familiar with Racket.

Agree; there are multiple issues in Poetry's Github associated with installing inside Docker. If that's fixed, I'd be much happier with it.

The point about the beginners is solid, but consider the use case for Poetry: you need it if you want to package and publish a library, which is not an area I would associate with beginners.

Not on my phone from the subway, but maybe when I'm back at home I'll take the time.

Here we go :)

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.

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

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:

    "python -m pip install poetry --user"
    "python -m poetry init"

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

2 - 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" (https://github.com/pantsbuild/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 :)

3 - 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: https://setuptools.readthedocs.io/en/latest/setuptools.html#...

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: https://pypi.org/project/twine/

You could use "python setup.py bdist_wheel upload" instead of twine. It will work, but it's deprecated.

4 - Using pew

Pew (https://github.com/berdario/pew#usage) 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.

5 - 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: https://github.com/sdispater/poetry

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.

Kudos

In the link below it says, “Pipenv is recommended for collaborative projects”

https://packaging.python.org/tutorials/managing-dependencies...

So my question is: who is in charge at PyPA, and how much Kenneth involved in it?

You are right about the hates for pipenv, but I don't know that the creator hates it too.

edit: sorry I misunderstood, the creator of pipenv doesn't hate pipenv

pip, virtualenv, setup.py using setuptools, and twine if you need to publish to PyPI, are all pretty old and well-established, and are all still a fine way to do python development.