Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This pretty much mirrors my experience trying to package Python code for any kind of use. Jesus it's a mess with pretty much everyone resorting incompatible 3rd party tooling. I really really hope it gets better and we eventually reach a turning point.

> Firstly, TOML. This is something I’ve been repeating for quite some time already, so I’ll just quickly go over it. I like TOML, I think it’s a reasonable choice for markup. However, without a TOML parser in stdlib (and there’s no progress in providing one), this means that every single build system now depends on tomli, and involves a circular dependency. A few months back, every single build system depended on toml instead but that package became unmaintained. Does that make you feel confident?

This seems crazy bad. I had naively assumed that when the PEP was adopted it included the parser. I genuinely can't believe they adopted an ini type format without a native parser when Python already has ConfigParser.



Yeah, that little bit made my jaw drop. Package manifests in a format the language doesn't have stdlib support for is insane.


Hmm. How does cargo handle this? TOML is not in the rust stdlib either.


I’m guessing the cargo binary has a TOML parser in it. As long as cargo itself doesn’t need TOML support to build that should be fine.


cargo itself does need TOML support to build because cargo itself is a Rust crate [0].

But it's not a problem because you build a new version of cargo with an older version of cargo that of course can parse TOML.

[0] https://github.com/rust-lang/cargo/blob/master/Cargo.toml




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: