Hacker News Reader

Comment by throwaway4007 | Hacker News Reader

I still don't understand why the Python steering committee decided to switch to this format for package configuration instead of the perfectly serviceable and existing setup.cfg. Packaging is already a pain to setup, now you gotta learn three (3) different ways to do it (if only to translate from one to the next) because everyone's split. The choice doesn't even matter very much, just settle on something whatever it is

View on HN

They did settle on something: TOML, in PEP 517/518. There are a ton of in-progress PEPs building on top of PEP 518 to make pyproject.toml the place to put package metadata in a way that will actually be standardized and usable by multiple different packaging tools. setup.cfg is just a crappy form of ini file, with no standards for what it contains other than "what do common tools do". It's a mess, and it's going to get better, but it takes time because consensus is hard and we're all doing this for free.

There's not much to learn. It's basically .ini on steroids.

It's not that it's hard. It's that it's different, and every difference has a cost. IMHO, and in the OP's opinion, the benefit of TOML for packages isn't worth the mental cost of having to know about three configuration methods.

What confuses me is why there isn't a toml module in the standard library.

I think the general feeling in the community is that the standard library is where packages go to die. Once something is in the standard library, it can't get meaningful features/updates outside of the yearly release cycle. pip and setuptools are already vendoring a TOML implementation, and once you have pip, you can pick from multiple great toml implementations that are all under active development. Maybe once the packages/standards for TOML are finalized and the only thing left to do is fix bugs, maybe then we'll see a TOML implementation in the standard library, but in the modern age where you can fetch dependencies at any time, there's honestly not that much incentive for CPython developers to take on more burden of maintenance and development for the already-massive standard library.

> the standard library is where packages go to die

I totally understand that sentiment. But that does seem to contradict the "batteries included" philosophy. Then again pip itself seems like one of the batteries you would expect to be included, so maybe that philosophy is just no longer as relevant to python.

my understanding is that the batteries included philosophy wasn't really successful. probably it would have been better if they had a smaller standard library providing core language-level functionality and then many blessed p packages that with independent versioning

It was successful at the time. Remember Python is nearly 30 years old now, and has always had the worst dependency management of any major language.

I don't know c++ dependency management is pretty terrible.

Python now includes pip itself in the standard library (which is a spectacularly poor decision IMO).

Nit: the standard library includes a module to fetch and install pip. It doesn't include pip itself.

Yeah, that's an issue in flake8. There is no stable standard library for something that is supposed to be core to python moving forward.

https://gitlab.com/pycqa/flake8/-/issues/428#note_251982786

Reply on news.ycombinator.com