Python Practical Package Packing 2024

While the author enumerates the things they think you should do, I think it was very light on the _why_ you would want this setup. I think the argument of "you are doing it the old way" have been really ineffective at convincing people to do anything different, particularly around python tooling.

The official docs recommend doing many of the things the author cautions against or calls bad. https://packaging.python.org/en/latest/guides/distributing-p...

Matt needs to stop this "I know better than you" attitude.

Seriously, first C and now Python.

I can't wait for the 20th revised version of this blog post where Matt has slowly realises he doesn't know half as much as he claims to and has added 50 side notes explaining all the cases where his blanket statement is not quite as broadly applicable as he ignorantly assumed.

Poetry is so slow, please use uv, for some of my projects, poetry takes 20-30 seconds to update/add new packages while uv completes it in seconds. But I can agree that's better to use a package manager than plain old `requirements.txt` file since you can pin the version you want to use for development or production.

Given how much the author talks about professional standards, one would think they would write professionally.

Also, is the author aware of why people use Anaconda? Conda environments can make it significantly easier to link CUDA or Fortran libraries properly, which are quite prevalent in scientific computing. Many people who use such code bases are professional scientists and not professional programmers, so I understand seeing that generally conda-based packages are poorly architected.

It's almost like other people sometimes do things differently because they have different needs or have thought of things you haven't, not just because they're too stupid or uneducated to know better.

I've been liking pdm as opposed to poetry, as poetry uses some non-standard syntax in the pyproject.toml file. I had a lot of trouble getting hatch environments to handle changes to default python versions and the like. I like how pdm played nicely out of the box with pyenv if you're using it, otherwise manages environments directly.

Nothing I have used so far in the Python ecosystem comes even close to Rye. Everything is incredibly fast, environments work across multiple operating systems, etc. For me, Poetry has been a massive headache (try installing PyQt6 Windows).

Just feel this needs to be solved higher up the pipeline than where they're trying to solve it. The fact multiple versions of the same library can't coexist in a project meaning you end up having to find this plateaux where every dependency is within range if they cross over. Node/NPM can do this, don't really see why Python couldn't eventually and read dependencies from within the project folder rather than this whole fake idea that it exists at a system level which just hasn't been the reality of how people are using this language for a long time.

For someone that is from the Ruby world and uses rbenv / bundler confortably, what would be the canonical way of using / managing Python in MacOS?

There seems to be a sea of alternatives and I see every tutorial mention `pip install` while I don't even have that running in my CLI (only pip3). Do people assume an alias here of I have somehow messed up my environment?

I think it's fine to have high-concept dependency management for the Serious Python Professionals, but what about for people who just want to put a project together and not have their life taken over by figuring out YAML syntax, new-hotness build tools, and dependency graph structures?

Due to supply-chain attacks, for your cybersecurity, I strongly encourage everyone to use a container for each project for development purposes. I do this using devcontainer.json in VSCode which is free. PyCharm too offers devcontainer integration but not for free, so I moved away from PyCharm. You can alternatively use a plain docker container if your IDE integrates with it, but devcontainer is more suited for this purpose. All this is assuming that you don't use a web IDE which already offers project isolation.

Please let the magical pi version of py, 3.14, get python to a suitable, standardized vessel for packaging.

I realize the Venn of packaging has copious disjoint functionality slices.

Too, what one does for a bit of one-off, non-typed cloud manipulation is different than for a full-on, re-usable library.

But the fabulous disaster that is the python packaging landscape was tiresome a decade ago.

Maybe the PSF can sponsor a kickstarter so that peanut gallery mouths like mine can contribute funds where our skills are tapering off.

I will change my projects to use pyproject.toml and remove all the requirements.txt. Looking forward to changing it again for py_requirements.yatxml in 5 years

Enjoyed the article, I think it mentions some good practices, although it’s missing some topics that may or may not be worth including, depending on your view of what constitutes ‘packaging’ in python.

This bit towards the end certainly came out of left field, but made me laugh:

dawn your peepers on some of these fun adventures in hiring i’ve had recently:

rejected in interviews by a 25 year old senior hiring manager rejected in interviews by a 28-something who had worked at google for 5 years and had a PhD from stanford rejected for arguing, akshually, i made more 10 years ago than what your scale is rated at rejected by some founders who got rich by selling an ios fart app to apple ten years ago rejected via HR/email/auto-reject a couple places at least nobody has ever accused me of not being sufficiently candid.

> BAD: you use the built-in python logging module. It is a complete disaster of an API. You should use loguru everywhere instead.

???

Isn't `src`, as in `src/packagename/__init__.py`, a thing any more?

tl;dr use poetry and write decent code