Hacker News Reader

Comment by mindwok | Hacker News Reader

I tried PDM earlier this year and there's a few things worth noting:

- PEP582 which it is based on is still in draft, and some tools (VS Code) won't fully support it until it's accepted.

- If you want to develop or test using different Python versions, you still need to use a virtual environment. PDM does handle this for you though.

IMO, the Python packaging ecosystem has been a dumpster fire for a long time, but the flurry of recent PEPs that provide a standard way of defining a package with pyproject.toml have made it so much better. Now it's just a matter of the tools catching up.

View on HN

Dumpster fire compared to what? Nuget? NPM? It may be that some more recent languages managed to start a saner solution and keep it sane.

But really, it's a hard problem, between cross-platform support, backwards compatibility, security concerns, hosting, most authors being volunteers and so on.

And still, even with "just" pip or even conda I am enjoying the Python experience more than some other packaging solutions I've seen.

It's objectively a dumpster fire. I don't care about other languages also being a dumpster fire on the packaging front, because I don't use other languages :) It also doesn't help me to know that NPM or .NET have rubbish packaging systems, that's their problem and not mine. I'd primarily want python's packaging system to be good.

I mean, just look at this thread. Someone asks "So in light of this, what should I use for python packaging?", and they get two dozen different answers loaded with weirdness like pyenv, python-venv, virtualenvwrapper, etc... If I wasn't using python, I would've thought this is some cruel python in-joke that outsiders don't get.

Just looking at those names, I'm already confused as to what the hell each are doing and why do I need them?

But let's go back to pip and conda. Conda is unbearably slow. Pip is not entirely reliable in resolving versions properly. There's also not entirely cooperative interaction between conda and pip. If you use conda, you should not use pip (or just minimally) because it'll result in a mess.

Yes, packaging is hard, but it feels like python has managed to solve (or not solve) it in a uniquely obtuse and bad way so far.

Hopefully the slew of new PEPs will finally bring some clarity to this mess.

When you say Python's way is uniquely obtuse, you are making a comparison to other packaging systems.

Labeling something a "dumpster fire" is a value judgement. It can't be "objective", unless there is a physical dumpster that is burning. It's not like the Python community hasn't solved this problem because it's lazy or incompetent. It's just a hard problem.

> Pip is not entirely reliable in resolving versions properly

It must be true because people say something like this any time a "python packaging sucks" thread comes along ... but I can't recall ever experiencing that in 10 years of Python-ing

The people having problems always seem to mention Conda though

I guess the parts that have problems are primarily where FFI and compilation or linking of non-Python code is happening?

Compared to nothing. Dumpster fire just means it sucks. To be fair, most of them do though.

If Python’s packaging is a dumpster fire, then what is Perl’s packaging?

Whoa there. Setting aside the stagnation of Perl due to the v6 debacle (which, by the way, Python 3 came very close to succumbing to the same fate), CPAN is widely recognized as a very successful package system, and is frequently the envy of many other languages. DBI, the Net:: space, and many others just work, and the package names follow common sense.

Reply on news.ycombinator.com