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 >