Hello

I asked "why changing the name" because (OK, I'm the author of some, but
not all) :
- On Fedora/EPEL : it is lark-parser
https://src.fedoraproject.org/rpms/python-lark-parser
- On gentoo : it is lark-parser
https://github.com/gentoo/gentoo/tree/master/dev-python/lark-parser
- On Arch Linux : it is lark-parser
https://www.archlinux.org/packages/community/any/python-lark-parser/
- On OpenSuse : it is lark-parser
https://software.opensuse.org/package/python-lark-parser

After that, I understand all arguments. I let you choose the final name. In
the end, the most important is to be able to do "import lark" :)

Regards

Thomas

Le lun. 30 déc. 2019 à 21:43, Simon McVittie <s...@debian.org> a écrit :

> 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 via email to