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

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

Alternative libraries for PEP-594

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

Contents

  Alternative libraries for PEP-594 Louis-Philippe Véronneau <pollo@debian.org> - 2024-08-02 09:20 +0200
    Re: Alternative libraries for PEP-594 Alexandre Detiste <alexandre.detiste@gmail.com> - 2024-08-02 10:30 +0200
      Re: Alternative libraries for PEP-594 Salvo Tomaselli <tiposchi@tiscali.it> - 2024-08-02 11:00 +0200
      Re: Alternative libraries for PEP-594 Louis-Philippe Véronneau <pollo@debian.org> - 2024-08-02 11:20 +0200
        Re: Alternative libraries for PEP-594 eevelweezel <eevel.weezel@gmail.com> - 2024-08-02 11:40 +0200
        Re: Alternative libraries for PEP-594 Alexandre Detiste <alexandre.detiste@gmail.com> - 2024-08-02 11:50 +0200
        Re: Alternative libraries for PEP-594 Salvo Tomaselli <tiposchi@tiscali.it> - 2024-08-02 14:20 +0200
          Re: Alternative libraries for PEP-594 Andrey Rakhmatullin <wrar@debian.org> - 2024-08-02 14:40 +0200
            Re: Alternative libraries for PEP-594 Salvo Tomaselli <tiposchi@tiscali.it> - 2024-08-02 16:10 +0200
              Re: Alternative libraries for PEP-594 Louis-Philippe Véronneau <pollo@debian.org> - 2024-08-03 03:10 +0200
                Re: Alternative libraries for PEP-594 Salvo Tomaselli <tiposchi@tiscali.it> - 2024-08-03 15:50 +0200
        Re: Alternative libraries for PEP-594 Emmanuel Arias <eamanu@debian.org> - 2024-08-03 11:30 +0200
      Re: Alternative libraries for PEP-594 Blair Noctis <n@sail.ng> - 2024-08-02 12:30 +0200
        Re: Alternative libraries for PEP-594 Alexandre Detiste <alexandre.detiste@gmail.com> - 2024-08-02 13:00 +0200
          Re: Alternative libraries for PEP-594 Blair Noctis <n@sail.ng> - 2024-08-02 13:50 +0200
            Re: Alternative libraries for PEP-594 Simon McVittie <smcv@debian.org> - 2024-08-02 14:10 +0200
              Re: Alternative libraries for PEP-594 Blair Noctis <n@sail.ng> - 2024-08-02 14:30 +0200
            Re: Alternative libraries for PEP-594 Salvo Tomaselli <tiposchi@tiscali.it> - 2024-08-02 14:20 +0200
              Re: Alternative libraries for PEP-594 Blair Noctis <n@sail.ng> - 2024-08-02 14:30 +0200
            Re: Alternative libraries for PEP-594 Louis-Philippe Véronneau <pollo@debian.org> - 2024-08-03 03:50 +0200
              Re: Alternative libraries for PEP-594 Étienne Mollier <emollier@debian.org> - 2024-08-03 10:30 +0200
            Re: Alternative libraries for PEP-594 Louis-Philippe Véronneau <pollo@debian.org> - 2024-08-03 07:30 +0200
              Re: Alternative libraries for PEP-594 Matthias Klose <doko@debian.org> - 2024-08-03 10:10 +0200
                Re: Alternative libraries for PEP-594 Louis-Philippe Véronneau <pollo@debian.org> - 2024-08-11 15:40 +0200
            Re: Alternative libraries for PEP-594 Alexandre Detiste <alexandre.detiste@gmail.com> - 2024-08-03 15:00 +0200

Page 1 of 2  [1] 2  Next page →

#16146 — Alternative libraries for PEP-594

Hello,

In the 2nd Python BoF today, it was pointed out we should probably make sure the alternatives listed in PEP-594 for libraries removed in 3.13 are packaged in Debian.

I had a look, and these are the ones that should be packaged (all the other ones are already in the archive). There are no RFP open for them either:

crypt:
* legacycrypt: standalone version of crypt [1]

telnetlib:
* telnetlib3: a Telnet Client and Server library for python [2]
* exscript: automating network connections over protocols such as Telnet or SSH [3]

Is anyone in the DPT interested in packaging and maintaining these libraries? They will likely be very useful for the 3.13 transition.

 From the stats I have, I currently count:

* 37 packages using telnetlib
* 300 packages using crypt

[1]: https://pypi.org/project/legacycrypt/
[2]: https://github.com/jquast/telnetlib3/
[3]: https://github.com/knipknap/exscript/

-- 
   ⢀⣴⠾⠻⢶⣦⠀
   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
   ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
   ⠈⠳⣄

[toc] | [next] | [standalone]

#16147

Hi,

I will need some "zombie-telnetlib" (so exactly the same API as
existing telnetlib)
because I maintain proprietary .deb (not "Debian packages") that need
to be installable without rebuild on Buster, Bookworm & Trixie.

I understand that "telnetlib3" / "exscript" are 'better/newer' API but
that does not fit the need.

Debian could also benefit from this zombie-telnetlib.

Should it be a native package or one with real upstream on PyPi ?

Greetings

Le ven. 2 août 2024 à 09:13, Louis-Philippe Véronneau
<pollo@debian.org> a écrit :
> telnetlib:
> * telnetlib3: a Telnet Client and Server library for python [2]
> * exscript: automating network connections over protocols such as Telnet or SSH [3]
>
> Is anyone in the DPT interested in packaging and maintaining these libraries? They will likely be very useful for the 3.13 transition.
>
>  From the stats I have, I currently count:
>
> * 37 packages using telnetlib

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

#16148

You can do conditional dependencies on those packages.

Like python3.13 | python3-xxxx

Then it will be installable on both.

In data venerdì 2 agosto 2024 10:21:55 CEST, Alexandre Detiste ha scritto:
> Hi,
> 
> I will need some "zombie-telnetlib" (so exactly the same API as
> existing telnetlib)
> because I maintain proprietary .deb (not "Debian packages") that need
> to be installable without rebuild on Buster, Bookworm & Trixie.
> 
> I understand that "telnetlib3" / "exscript" are 'better/newer' API but
> that does not fit the need.
> 
> Debian could also benefit from this zombie-telnetlib.
> 
> Should it be a native package or one with real upstream on PyPi ?
> 
> Greetings
> 
> Le ven. 2 août 2024 à 09:13, Louis-Philippe Véronneau
> 
> <pollo@debian.org> a écrit :
> > telnetlib:
> > * telnetlib3: a Telnet Client and Server library for python [2]
> > * exscript: automating network connections over protocols such as Telnet
> > or SSH [3]
> > 
> > Is anyone in the DPT interested in packaging and maintaining these
> > libraries? They will likely be very useful for the 3.13 transition.> 
> >  From the stats I have, I currently count:
> > * 37 packages using telnetlib


-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
                -- Galileo Galilei

https://ltworf.codeberg.page/

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

#16149

On 2024-08-02 17:21, Alexandre Detiste wrote:
> Hi,
> 
> I will need some "zombie-telnetlib" (so exactly the same API as
> existing telnetlib)
> because I maintain proprietary .deb (not "Debian packages") that need
> to be installable without rebuild on Buster, Bookworm & Trixie.
> 
> I understand that "telnetlib3" / "exscript" are 'better/newer' API but
> that does not fit the need.
> 
> Debian could also benefit from this zombie-telnetlib.
> 
> Should it be a native package or one with real upstream on PyPi ?

That was another item we discussed during the 2nd BoF. There are already 
some projects like these [1][2] and we were considering packaging them 
to ease the 3.13 transition.

eamanu said he would make a list of upstream projects we could package, 
but if you have some time, getting a list of projects would be great.

If we end up packaging these libraries, I think it should be clear that 
they won't be available for Forky (Debian 14). The last thing we want is 
to maintain some deprecated zombie-libraries forever in Debian :(

Cheers,

[1]: https://github.com/simonrob/pyasyncore
[2]: https://github.com/tiran/legacycrypt

-- 
   ⢀⣴⠾⠻⢶⣦⠀
   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
   ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
   ⠈⠳⣄

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

#16150

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

I could work on legacycrypt.

On Fri, Aug 2, 2024 at 4:19 AM Louis-Philippe Véronneau <pollo@debian.org>
wrote:

> On 2024-08-02 17:21, Alexandre Detiste wrote:
> > Hi,
> >
> > I will need some "zombie-telnetlib" (so exactly the same API as
> > existing telnetlib)
> > because I maintain proprietary .deb (not "Debian packages") that need
> > to be installable without rebuild on Buster, Bookworm & Trixie.
> >
> > I understand that "telnetlib3" / "exscript" are 'better/newer' API but
> > that does not fit the need.
> >
> > Debian could also benefit from this zombie-telnetlib.
> >
> > Should it be a native package or one with real upstream on PyPi ?
>
> That was another item we discussed during the 2nd BoF. There are already
> some projects like these [1][2] and we were considering packaging them
> to ease the 3.13 transition.
>
> eamanu said he would make a list of upstream projects we could package,
> but if you have some time, getting a list of projects would be great.
>
> If we end up packaging these libraries, I think it should be clear that
> they won't be available for Forky (Debian 14). The last thing we want is
> to maintain some deprecated zombie-libraries forever in Debian :(
>
> Cheers,
>
> [1]: https://github.com/simonrob/pyasyncore
> [2]: https://github.com/tiran/legacycrypt
>
> --
>    ⢀⣴⠾⠻⢶⣦⠀
>    ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
>    ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
>    ⠈⠳⣄
>
>

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

#16151

Le ven. 2 août 2024 à 11:19, Louis-Philippe Véronneau
<pollo@debian.org> a écrit :
> > Should it be a native package or one with real upstream on PyPi ?
So it seems there's a global need for those zombie-libraries.

> eamanu said he would make a list of upstream projects we could package,
> but if you have some time, getting a list of projects would be great.

Just add those there + mention these are not yet packaged:

https://wiki.debian.org/Python/Dead%20Batteries

> The last thing we want is to maintain some deprecated zombie-libraries forever in Debian :(
We don't want be we have to....

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

#16158

> If we end up packaging these libraries, I think it should be clear that
> they won't be available for Forky (Debian 14). The last thing we want is
> to maintain some deprecated zombie-libraries forever in Debian :(

The alternative to using asynccore might be major rewrites.

At this poinrt I think python is a joke.

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
                -- Galileo Galilei

https://ltworf.codeberg.page/

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

#16162

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

On Fri, Aug 02, 2024 at 02:11:41PM +0200, Salvo Tomaselli wrote:
> > If we end up packaging these libraries, I think it should be clear that
> > they won't be available for Forky (Debian 14). The last thing we want is
> > to maintain some deprecated zombie-libraries forever in Debian :(
> 
> The alternative to using asynccore might be major rewrites.
> 
> At this poinrt I think python is a joke.

Which is a popular opinion.
Still, asyncore was deprecated in 2016.

-- 
WBR, wRAR

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

#16164

> Which is a popular opinion.
> Still, asyncore was deprecated in 2016.

Eh, software is 8 years old so it needs a full rewrite now?


-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
                -- Galileo Galilei

https://ltworf.codeberg.page/

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

#16166

On 2024-08-02 23:06, Salvo Tomaselli wrote:
>> Which is a popular opinion.
>> Still, asyncore was deprecated in 2016.
> 
> Eh, software is 8 years old so it needs a full rewrite now?

Please try to keep comments that are not productive to the current 
efforts to some other channels?

That kind of email certainly doesn't motivate me to make things in 
Debian better :(

-- 
   ⢀⣴⠾⠻⢶⣦⠀
   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
   ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
   ⠈⠳⣄

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

#16176

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

In data sabato 3 agosto 2024 03:08:13 CEST, Louis-Philippe Véronneau ha 
scritto:
> On 2024-08-02 23:06, Salvo Tomaselli wrote:
> >> Which is a popular opinion.
> >> Still, asyncore was deprecated in 2016.
> > 
> > Eh, software is 8 years old so it needs a full rewrite now?
> 
> Please try to keep comments that are not productive to the current
> efforts to some other channels?
> 
> That kind of email certainly doesn't motivate me to make things in
> Debian better :(

I think I wasn't clear enough.

I don't think there's any sort of problem with us having a python3-
droppedmodule in debian forever (until nothing depends on it), if the dropped 
module has no security implications.

I don't think dropping software that works completely fine helps anyone, just 
because python upstream decided they didn't like some module any longer.

Best

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
                -- Galileo Galilei

https://ltworf.codeberg.page/

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

#16172

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

[snip]
> 
> eamanu said he would make a list of upstream projects we could package, but
> if you have some time, getting a list of projects would be great.
>

I add a section here [0]. I'm going add the modules there, please feel
edit it.


[0] https://wiki.debian.org/Python/Dead%20Batteries#preview


Cheers,
Emmanuel
[snip]

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

#16152

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

On 02/08/2024 16:21, Alexandre Detiste wrote:
> Hi,
> 
> I will need some "zombie-telnetlib" (so exactly the same API as
> existing telnetlib)
> because I maintain proprietary .deb (not "Debian packages") that need
> to be installable without rebuild on Buster, Bookworm & Trixie.

It's just /usr/lib/python3.12/telnetlib.py. You can probably copy it to your
"proprietary" .deb and continue using it.

> I understand that "telnetlib3" / "exscript" are 'better/newer' API but
> that does not fit the need.

Hopefully the need can be fulfilled by a clever rewrite and/or an external library.

> Debian could also benefit from this zombie-telnetlib.

How?

On the other hand, it would allow packages to continue relying on a thing
expunged from upstream, a maintenance burden for both Debian and upstream.

-- 
Sdrager,
Blair Noctis

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

#16153

Le ven. 2 août 2024 à 12:25, Blair Noctis <n@sail.ng> a écrit :
> > Debian could also benefit from this zombie-telnetlib.
>
> How?
>
> On the other hand, it would allow packages to continue relying on a thing
> expunged from upstream, a maintenance burden for both Debian and upstream.

If we for example need to patch 10 dead-upstream projects to re-add telnetlib.py
& the corresponding stanza in d/copyright it might be less work
to scale it out in an external source package.

All of this depends on how many packages will need this telnetlib.

codesearch gives pages and pages of stuff with a lot of false positives

https://codesearch.debian.net/search?q=telnetlib&literal=1&perpkg=1&page=5

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

#16154

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

On 02/08/2024 18:55, Alexandre Detiste wrote:
> Le ven. 2 août 2024 à 12:25, Blair Noctis <n@sail.ng> a écrit :
>>> Debian could also benefit from this zombie-telnetlib.
>>
>> How?
>>
>> On the other hand, it would allow packages to continue relying on a thing
>> expunged from upstream, a maintenance burden for both Debian and upstream.
> 
> If we for example need to patch 10 dead-upstream projects to re-add telnetlib.py
> & the corresponding stanza in d/copyright it might be less work
> to scale it out in an external source package.
> 
> All of this depends on how many packages will need this telnetlib.
> 
> codesearch gives pages and pages of stuff with a lot of false positives
> 
> https://codesearch.debian.net/search?q=telnetlib&literal=1&perpkg=1&page=5

Searching in regex mode with `import.*telnetlib path:*.py` should give more
accurate results. But nevertheless:

Yeah, if they have not migrated. This PEP was first proposed in 2019, amended in
2022, and 3.13 is slanted to be released in October, 2024. Package authors
should have had plenty of time to have this information propagated to them and
migrate. Even today, 2 Aug 2024, is 2 months from the effective date. Please
file bugreports/issues to ask the packages you care about to migrate.

> If we for example need to patch 10 dead-upstream projects

which means the maintainer is now responsible for keeping it up to date.
Including following Python upgrades and PEPs. But not by

> to scale it out in an external source package

which is effectively going against Python upstream, allowing the thing to live
on, and people to say "it's still alive in Debian!"

Also, even python3.11 is still there. Sure someone needing something expunged
from 3.13 would be fine staying with 3.12?

-- 
Sdrager,
Blair Noctis

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

#16156

On Fri, 02 Aug 2024 at 19:40:59 +0800, Blair Noctis wrote:
> Even today, 2 Aug 2024, is 2 months from the effective date. Please
> file bugreports/issues to ask the packages you care about to migrate.

I agree with this part of what you said.

But, not this part:

> Also, even python3.11 is still there. Sure someone needing something expunged
> from 3.13 would be fine staying with 3.12?

In unstable, yes, at least temporarily; but not forever (and 3.11 has
already disappeared from testing).

Also, many Debian developers think of our stable releases as being our
primary deliverable, with testing/unstable only being a tool that we
use to make the next stable release. In stable, we generally only have
one version of Python (for example Debian 12 has Python 3.11 and no
other version), because the Python maintainers and other core teams do not
have the resources to security-support more than one branch for 3 years.

    smcv

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

#16160

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

On 02/08/2024 20:07, Simon McVittie wrote:
> On Fri, 02 Aug 2024 at 19:40:59 +0800, Blair Noctis wrote:
>> Even today, 2 Aug 2024, is 2 months from the effective date. Please
>> file bugreports/issues to ask the packages you care about to migrate.
> 
> I agree with this part of what you said.
> 
> But, not this part:
> 
>> Also, even python3.11 is still there. Sure someone needing something expunged
>> from 3.13 would be fine staying with 3.12?
> 
> In unstable, yes, at least temporarily; but not forever (and 3.11 has
> already disappeared from testing).
> 
> Also, many Debian developers think of our stable releases as being our
> primary deliverable, with testing/unstable only being a tool that we
> use to make the next stable release. In stable, we generally only have
> one version of Python (for example Debian 12 has Python 3.11 and no
> other version), because the Python maintainers and other core teams do not
> have the resources to security-support more than one branch for 3 years.

Sorry, I daily drive unstable and overlooked that part. My apologies.

Though as you said, current stable bookworm/12 has 3.11, which definitely has
those modules; next stable trixie/13 might have 3.13, but it would be frozen in
2025, by then we should have worked this out.

-- 
Sdrager,
Blair Noctis

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

#16157

> Package authors should have had plenty of time to have this information
> propagated to them and migrate. 

In general, stuff that works doesn't receive many updates. And thinght might be 
abandoned upstream but still work fine and be used as dependencies for other 
things.


-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
                -- Galileo Galilei

https://ltworf.codeberg.page/

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

#16159

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

On 02/08/2024 20:14, Salvo Tomaselli wrote:
>> Package authors should have had plenty of time to have this information
>> propagated to them and migrate. 
> 
> In general, stuff that works doesn't receive many updates.

Yes, in fact I quite like the concept of "feature-complete passive maintenance".
However, it doesn't conflict with updating with upstream/language.

> And thinght might be 
> abandoned upstream but still work fine and be used as dependencies for other 
> things.

Covered in another email:

>> If we for example need to patch 10 dead-upstream projects
> 
> which means the maintainer is now responsible for keeping it up to date.
> Including following Python upgrades and PEPs.

-- 
Sdrager,
Blair Noctis

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

#16167

On 2024-08-02 20:40, Blair Noctis wrote:
>>
>> https://codesearch.debian.net/search?q=telnetlib&literal=1&perpkg=1&page=5
> Searching in regex mode with `import.*telnetlib path:*.py` should give more
> accurate results. But nevertheless:

I did this work already in Lintian:

https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Languages/Python/StdlibDeprecation.pm?ref_type=heads

The current code for "uses-deprecated-python-stdlib" in Sid is flawed 
(see #1077324) but that will be fixed in the next Lintian release.

When that happens, I'm planning on making a MBF.

-- 
   ⢀⣴⠾⠻⢶⣦⠀
   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
   ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
   ⠈⠳⣄

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web