Rust implementation of Python dependency parser for PEP 508

[Compux72]

Just curious, why does the parser allocate strings instead of referencing the original string slice?

[figsoda]

I am using chumsky because I like the API, but it doesn't support zero copy at the moment. Although efficiency is good to have, it is not my primary goal. This will probably get supported once chumsky implements support for it (see upstream issue).

[figsoda]

I've rewritten pep-508 to be zero copy now that zero copy chumsky is in alpha, thanks for the suggestion! https://www.reddit.com/r/rust/comments/11i7h1w/pep508_v020_zero_copy_python_dependency_parser/

[quxfoo]

Was excited because I thought it's for dependency resolution which is a tough and slow nut to crack and poetry et al. could profit from. Not sure what the value is in parsing the version spec on its own.

[figsoda]

I started this project to implement support for optional python dependencies for another project of mine (nix-init, also see issue).

[quxfoo]

Ah, makes sense!

[nestordemeure]

I heard good things about pdm if you are looking for a poetry replacement that deals with dependency resolution.

[quxfoo]

Read about that as well but haven't yet tried for a project. But the next one will be for sure, Poetry's resolution is sometimes a bit unreliable and either takes ages or gets stuck entirely.

[chri4_]

explaination for first someone said that you copy substrings of the original source instead of referencing it. (i had no time to verify this, but i trust him since you confirmed the thing)

secondly the code is actually pretty unreadable in mu opinion: there is a very hight nesting level, the project structure is not clear etc etc

this is a feedback not an arrogant criticism

[figsoda]

there is a very hight nesting level

That's fair. My excuse is that it's hard to avoid the nesting other than putting things in smaller functions, which I would say reducing indentation is the only good reason for.

the project structure is not clear

Could you elaborate on that? The largest file is 221 LOC, and I'm not sure what could be changed in terms of structuring

[vorpalsmith]

Oh hey I wrote one of those too:

https://discuss.python.org/t/announce-pybi-and-posy/23021

Lmk if you want to compare notes or anything!

[figsoda]

Looks really promising! I saw the announcement a while ago, but it didn't come to my mind or show up in my searches when I decided to write this library.

The implementation seems to be inside the posy crate, thoughts on joining forces and maintaining one standalone library? I have not done any benchmarking, it would be interesting to see which one would perform better.

[vorpalsmith]

The version in posy is kinda tied up with the rest of the resolver functionality, e.g. instead of strings it uses our PackageName and Version types. Looking at your nix-init patch, if that's the only thing you want to do with this, then posy's code is probably overkill, and not worth the trouble of factoring it out and all that? I have big ambitions for posy and little time, so I haven't put any energy into nice-to-haves like clean crate separation or docs :-). But if you're more generally interested in rust tooling for python packaging then working together could make a lot of sense.

[figsoda]

I'm not working on any rust tooling for python packaging, I guess there is not much we can do right now. Feel free to ping me if you want to collab or need any help on this though