Re: name change: python-lark-parser -> python-lark
On Mon, 30 Dec 2019 at 17:15:54 +0100, Peter Wienemann wrote:
> https://bugs.debian.org/945823
>
> which says:
>
> "use the name you import in preference to the name from the PKG-INFO".
>
> That is why I decided to change the name to python-lark. But given the
> PyPI name clash this is certainly not optimal either. So this seems to
> be a particular unfortunate case.
If there are two modules on PyPI, both of which you use via
"import lark", then they cannot both be installed correctly into the
system-wide module search path on the same Debian system - if they
were, even if they happen to avoid having directly conflicting files
(because one is /usr/lib/python3/dist-packages/lark.py and the other is
/usr/lib/python3/dist-packages/lark/__init__.py, or similar), installing
both and using "import lark" would not consistently import the one you
intended to use, leading to broken programs.
So the rule has served its purpose: it has detected a conflict that needs
to be avoided somehow.
For users of virtualenv there is perhaps no problem, because you can
install the lark you wanted in a particular virtualenv and avoid installing
the other lark, but Debian packages are a flat global namespace of modules.
There are two options:
* If "lark" on PyPI is a dead project, or otherwise something that is never
going to be useful to package in Debian for some reason, then perhaps it's
safe for the lark parser to claim the python3-lark name.
* Otherwise, if its PyPI name is lark-parser, then I would personally
recommend asking the upstream developer to rename the module you import
to lark_parser (or maybe larkparser if that's preferred), and packaging
it as python3-lark-parser (or python3-larkparser), optionally with
compatibility glue to make "import lark" continue to work (which might not
get packaged in Debian).
(I'm talking about binary package names python3-foo because those are the
most important thing for avoiding conflicts, but if the binary package
name is python3-foo then it probably makes most sense for the source
package to be python-foo.)
smcv
Reply to: