the alioth mailing list is full of spam

[shirish शिरीष]

Dear all,

See [1] . All the messages therein are spam. If it not being used
maybe people can write to the alioth admin [2] and let him know that
either the service is not required or perhaps somehow get it cleaned
up. In November, only one mail was of interest which was of py2removal
otherwise the rest were also spam. I know it's supposed to be a time
limited service according to its own pages [3] but they haven't shared
any concrete plans for it, at least publically.

1. 
https://alioth-lists.debian.net/pipermail/pkg-python-debian-maint/2019-December/thread.html

2. ad...@alioth-lists.debian.net

3. https://wiki.debian.org/Alioth/MailingListContinuation

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

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

[Peter Wienemann]

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

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

[Simon McVittie]

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

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

[Peter Wienemann]

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

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

[Thomas Andrejak]

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

Request to (re)join Python team

[Utkarsh Gupta]

Hello everyone,

I'd like to migrate my current membership of the Python team to use my
new Salsa login, i.e., utkarsh \o/
(Previously it was utkarsh2102-guest)

Requesting you to please grant access for both, DPMT and PAPT, once again :)

I've read the policy[1] and accept it.


Best,
Utkarsh
---
[1]:
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst



signature.asc
Description: OpenPGP digital signature

python-requests: adding a documentation package python-requests-doc

[Fabrice BAUZAC-STEHLY]

Hello,

I wish there was a python-requests-doc package for browsing
python-requests' documentation offline.  I'd like to add it if I can.

I saw that debian/watch currently targets the PyPI tarball, which lacks
the documentation.

As a first step, I'm submitting a merge request [1] so that debian/watch
tracks the github releases instead, which do contain the documentation.

After that, once a new upstream release of requests is published and
propagated into the salsa repository, the latter will start
containing the missing docs/ subdirectory.  So we'll at least be able to
start working on a new python-requests-doc binary package containing the
documentation.

In the merge request, I've basically applied the github recipe as
indicated in the uscan(1) manpage.

If you could have a look at this merge request, that would be excellent.

[1] https://salsa.debian.org/python-team/modules/requests/merge_requests/1

Thanks a lot!

Best regards

--
Fabrice BAUZAC-STEHLY
PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D