Fixed the parser regression for the package names starting with the the same substrings as keywords.

[KOLANICH]

introduced in 2e5593c

Fixes: #618

Note: please never ever hand-rewrite parsers, it is very error-prone. My experience with parsers says to me that it is better to deal with them as grammars being fed to parser generators. That will notify you about conflicts and do a lot of work for you.

Shameless plug: UniGrammar is an abstraction layer for parser generators and their runtimes.

[brettcannon]

please never ever hand-rewrite parsers, it is very error-prone.

Unfortunately we needed to drop our dependency on pyparsing to be dependency-free. That led to someone contributing the hand-written parser, so we accepted the contribution. Had someone contributed a parser-generator solution that generating a static parser we could check into the repository, we would have accepted that, but alas that was not what was given to us.

[brettcannon]

Unfortunately the code is failing type checks.

[KOLANICH]

Thanks for the fix, added it.

Unfortunately we needed to drop our dependency on pyparsing to be dependency-free.

TBH: I know this issuel but it is not so big issue. There are pretty a lot of cyclic dependencies (I have to work around them with custom build scripts and PYTHONPATH modification), untying packaging from pyparsing is only one of them. Besides pip, wheel and setuptools there are also flit_core and hatchling, all having a dependency that needs them to build itself. See https://github.com/KOLANICH-tools/ipi.py/blob/master/ipi/bootstrap/setuptools.py for more infol

Had someone contributed a parser-generator solution that generating a static parser we could check into the repository, we would have accepted that, but alas that was not what was given to us.

1. What's the problem to choose the parser generator with the smallest runtime and vendor the runtime?
2. Why not to use regexps instead of an own tokenizer? The structure of the requirement feels like it can be tokenized with a regexp (disclaimer: I have not tried to implement it this way, so I can be wrong about it), and I guess a regexp would be more readable than the custom tokenizer.

[brettcannon]

1. What's the problem to choose the parser generator with the smallest runtime and vendor the runtime?

Could have been another option. Once again, the solution we were presented with was this hand-written parser.

2. Why not to use regexps instead of an own tokenizer?

See above. 😁

[KOLANICH]

I guess you may want to try waxeye parser gen, it has a rather compact runtime. But again, TBH I currently don't consider packaging having a dependency like pyparsing (or waxeye) as a big issue.

[pradyunsg]

Hmm... this is a bit more broken. Names like v0, a0 are also being picked up incorrectly (anything that matches VERSION).

I'll dig into the hand-written parser and spend some cycles on it to see what we might want to change about it. :)