Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #12176 > unrolled thread

Re: name change: python-lark-parser -> python-lark

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: name change: python-lark-parser -> python-lark Peter Wienemann <fossdev@posteo.de> - 2019-12-30 17:20 +0100
    Re: name change: python-lark-parser -> python-lark Simon McVittie <smcv@debian.org> - 2019-12-30 18:20 +0100
      Re: name change: python-lark-parser -> python-lark Peter Wienemann <fossdev@posteo.de> - 2019-12-30 20:30 +0100
      Re: name change: python-lark-parser -> python-lark Thomas Andrejak <thomas.andrejak@gmail.com> - 2019-12-30 22:20 +0100

#12176 — Re: name change: python-lark-parser -> python-lark

Hi Thomas,

I am including the Python team to tap their expertise.

For those not familiar with the topic: We are referring to

https://github.com/lark-parser/lark

which is not in the Debian archive yet (packaging work is still ongoing).

On 29.12.19 23:10, Thomas Andrejak wrote:
> Why changing the name ? it's named lark-parser in pypi.

>From the beginning I felt uncertain how to call the source package:
python-lark-parser or python-lark.

> Moreover, in pypi, there already is a "lark" module which is not lark-parser

When filing the ITP bug I decided to choose python-lark-parser for
exactly this reason although upstream seems to call its software simply
"Lark" in most places.

Later I became aware of

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.

Any advice is welcome!

Peter

> Le sam. 28 déc. 2019 à 05:03, Peter Wienemann <fossdev@posteo.de
> <mailto:fossdev@posteo.de>> a écrit :
> 
>     Following the suggestions in
> 
>     https://bugs.debian.org/945823
> 
>     I have changed the name from python-lark-parser to python-lark.
> 
>     The new repository URL is
> 
>     https://salsa.debian.org/python-team/modules/python-lark
> 
>     Peter

[toc] | [next] | [standalone]

#12177

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

[toc] | [prev] | [next] | [standalone]

#12178

Hi Simon,

thanks for your helpful input.

On 30.12.19 18:04, Simon McVittie wrote:
> 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.

The last commit happened six years ago. It might be dead but I am not sure.

> * 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 opened a corresponding issue:

https://github.com/lark-parser/lark/issues/505

Peter

[toc] | [prev] | [next] | [standalone]

#12179

[Multipart message — attachments visible in raw view] — view raw

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 <smcv@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
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web