This stuff has got SO MUCH better over the past few years.

The hardest thing about it these days is mainly that there are so many historical artifacts, so if you're trying to figure out how to use packaging there are a lot of outdated resources.

Modern Python packages are really pleasant to work with. Here's the best current tutorial that I've seen: https://packaging.python.org/en/latest/tutorials/packaging-p...

I'm not so sure. I went down this rabbit hole. It's really a mess.

Setuptools? Poetry? Hatch? PBR? Flit? PDM? Why are there so many build systems? How do I choose the proper one?

The article you posted uses hatch, which I hadn't even heard of until last week.

Should I use setup.py, setup.cfg, or pyproject.toml? Things seem to moving to pyproject.toml but lots of existing functionality seems to point to setup.py. Looking for answers on SO seems to result in a mix of all different combinations.

And then there's virtual environments...

Ten years ago things were pretty bad, and I can see how it could be confusing trying to pick through all of the different options that have risen and fallen over the years.

In 2022, If you're building an application and are looking for a simple answer, just use Poetry; it's similar enough to what you'll be familiar with if coming from other languages (e.g. yarn, cargo, ...). For most usecases you can just lean on Poetry's venv management; you don't need to do more than `poetry shell` or `poetry run` to get access to it. Poetry will create, and for the most part manage, your pyproject.toml file for you.

If you want a bit more flexibility Virtualenv is part of python now (`python -m venv`). If you're on MacOS you can get great venv management with pyenv and pyenv-virtualenv. And for sure, things get more complex if you're building a library. But I think Poetry is a solid place to start.

I've used python on and off since 2009 and every time I dive back in, there's a new standard. I feel like there's several 'proper' ways to do things and I don't really mind there being different flavors of packaging frameworks.

I do find it confusing because there's no real documentation of the various frameworks in one place. It makes it unappealing to invest in writing and maintaining anything in python because I don't know if the process I've used is going to deprecated soon.

Just a side note, I did end up finding and using poetry a couple of weeks ago and stuck to that as I was bouncing around setuptools vs pyproject and then needing to decide whether or not I needed a makefile, etc.

But this directly contradicts the link given above - the "official" python packaging tutorial recommends Hatch, and barely mentions poetry...

"Just use X" is not what I want to hear. Python packaging is a pile of garbage. I don't want to have to use a 3rd party tool! Just fix the damn core tools and make them consistent and intuitive!

Sorry, rant over.

…and logging

But that's always the story with Python isn't it. There is always this new way to do things that is so much better than all the previous ones. If only everybody was doing it the right way. At least until the next one comes along.

We've come a long way since PEP 20.

Every time I see a language or a framework proclaim that it is designed so that there is one "right" or "obvious" way to do something, you can inevitably see that right way has changed multiple times over the course of its life, and it becomes obvious the larger an older any given project is.

I left one company 3 years ago in the middle of a major transition between versions. The "right way" changed fairly drastically, and surprise surprise, they're still stuck in the middle of that transition.

I think this is largely why I have found myself preferring static typing with roll-your-own framework style / library-based ecosystems over batteries-included systems.

When your language or framework of choice suddenly insists that you use AA batteries instead of button cells, and it is up to you to modify every electronic device in your house to use them, it gets real old real fast (an exaggerated example, but not entirely unheard of).

what I wish they would do is what Go does with dependencies. Package it up, compile it and turn it into a binary. This way I know 100% it will work on AWS Lambda for instance. I've spent ridiculous amount of time building dependencies that has to match Python versions and OS. AWS layers on github help save time but I don't know if I can trust strangers for this process.

Really should be, write stuff and test it locally on my machine, put it in a container and upload it. I know Lambda supports containers but sometimes I feel like its too much of an overhead, especially with shitty upload speeds but I really don't see any other choice unless I manually build AWS Lambda layers myself.

It's not perfect, but in my day to day use I find it relatively simple to use and as good as any other language's importing of packages.

Wait: does c++ have a package manager like pip or npm or gem that I didn't know about?

There are file system packages (with __init__.py) and PyPI packages.

The former are an extremely poor version of Lisp packages, OCaml modules or C++ name spaces.

The latter are distribution packages (even for distribution packages C++ has Conan etc.).

PyPI packaging gets even worse than usual when attempting to distribute a file system package.