> Why is this ecosystem considered acceptable?

It largely isn't, but python is a big ship and it takes time to turn. There's been a lot of movement in python packaging semi-recently and as far as I can tell using setup.py has been considered legacy for a while now.

Biggest problem is that the new way to do packaging is not documented very well. It's split over three or four different projects. It mostly amounts to "you need to make a pyproject.toml file" but it's somewhat tricky to find what such a file is even supposed to contain.

Speaking of poor programming practices, how about copy-pasting code without understanding it? Notice the author's mention of how many packages with -Ofast trace their lineage back through this comment:

    # Initially copied from
    # https://github.com/actions/starter-workflows/blob/main/ci/python-package.yml
    # And later based on the version jamadden updated at
    # gevent/gevent, and then at zodb/relstorage and zodb/perfmetrics

Although the linked config was modified 2 years ago to removed the unsafe math options[1], the copy-paste propagated before then.

Naturally anyone asking CoPilot, ChatGPT, or other modern LLM-based interface for config code will likely get something based on this, with the problematic -Ofast option included.

[1] https://github.com/zopefoundation/meta/commit/9c07520e90d9a1...

Not to mention that the Python packaging tutorial was missing a few bits, at least as of earlier this year: https://daveon.design/introducing-fontimize-subset-fonts-to-...

Again, why is this acceptable?

Okay, it's unacceptable. Now what? Sadly, we (you, I, the Python leadership) can't just visit every single Python package publisher/maintainer and ask politely but firmly ask them to fix their packaging issues. And even if we could, at least half of them would either ignore us or would mess up in some new, exciting ways while trying to adapt to the flavour du jour of Python packaging.

I think the answer is to not have a flavour du jour. Pick one, crown it the winner, document it well and give it some time. If the solution is always changing, nobody is going to want to put the effort in.

This is exactly our problem. We develop a couple of packages (which we don’t put on PyPI so any security issue is affects nobody except us). But it’s not our job and we cannot justify someone spending too much time on this. I have a look every now and then to try to figure out what we’re supposed to do, but there are 154 solutions, some of them are outdated and unmaintained, some of them are broken in more or less subtle ways, and some of them have a bare minimum of documentation. So yeah. We’ll change when we have a clear, documented path forward.

Just put your package folder into a tarball as-is; to install, execute

    tar xzf our_custom_package.tar.gz -C "$(python3 -c 'import sysconfig; print(sysconfig.get_path("platlib"))')"

I'm only half-joking.

> I think the answer is to not have a flavour du jour. Pick one, crown it the winner, document it well and give it some time.

It has been done with distutils: it has been around for more than a decade. The result is the ecosystem that you are complaining about.

This is really a great idea. Once we finalize the choice, when can we expect the upload into the hivemind?

Right after the maintainers of libtelepathy.so release the version with Discord support.

Well it's an ecosystem that is meant to be easy to use by people who don't know what they're doing.

The same problems happen in any language that links C and C++ libraries largely.

It's less common for other languages because they just don't do it as much.

You'll have to ask every developer why it's acceptable, because they keep using this ecosystem. And then ask their managers. But this is what happens when you don't use package ecosystems with maintainers being run by adults.

If I wanted to compile a Go binary using an existing dynamically loaded C library, compiled with -ffast-math, what happens?