Alternative libraries for PEP-594

[Louis-Philippe Véronneau]

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/

[Alexandre Detiste]

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

Post by Louis-Philippe Véronneau
* 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.
* 37 packages using telnetlib

[Salvo Tomaselli]

You can do conditional dependencies on those packages.

Like python3.13 | python3-xxxx

Then it will be installable on both.

Post by Alexandre Detiste
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

Post by Louis-Philippe Véronneau
* 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.>
* 37 packages using telnetlib

[Louis-Philippe Véronneau]

Post by Alexandre Detiste
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

[eevelweezel]

I could work on legacycrypt.

Post by Louis-Philippe Véronneau

Post by Alexandre Detiste
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
⠈⠳⣄

[Alexandre Detiste]

Le ven. 2 août 2024 à 11:19, Louis-Philippe Véronneau

Post by Louis-Philippe Véronneau

Post by Alexandre Detiste
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.

Post by Louis-Philippe Véronneau
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

Post by Louis-Philippe Véronneau
The last thing we want is to maintain some deprecated zombie-libraries forever in Debian :(

We don't want be we have to....

[Salvo Tomaselli]

Post by Louis-Philippe Véronneau
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.

[Andrey Rakhmatullin]

Post by Salvo Tomaselli

Post by Louis-Philippe Véronneau
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.

[Salvo Tomaselli]

Post by Andrey Rakhmatullin
Which is a popular opinion.
Still, asyncore was deprecated in 2016.

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

[Louis-Philippe Véronneau]

Post by Salvo Tomaselli

Post by Andrey Rakhmatullin
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 :(

[Salvo Tomaselli]

In data sabato 3 agosto 2024 03:08:13 CEST, Louis-Philippe Véronneau ha

Post by Louis-Philippe Véronneau

Post by Salvo Tomaselli

Post by Andrey Rakhmatullin
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

[Emmanuel Arias]

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

[Blair Noctis]

Post by Alexandre Detiste
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.

Post by Alexandre Detiste
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.

Post by Alexandre Detiste
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.

[Alexandre Detiste]

Post by Blair Noctis

Post by Alexandre Detiste
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

[Blair Noctis]

Post by Alexandre Detiste

Post by Blair Noctis

Post by Alexandre Detiste
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.

Post by Alexandre Detiste
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

Post by Alexandre Detiste
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?

[Simon McVittie]

Post by Blair Noctis
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.

Post by Blair Noctis
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

[Blair Noctis]

Post by Simon McVittie

Post by Blair Noctis
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.

Post by Blair Noctis
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.

[Salvo Tomaselli]

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.

[Blair Noctis]

Post by Salvo Tomaselli

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.

Post by Salvo Tomaselli
And thinght might be
abandoned upstream but still work fine and be used as dependencies for other
things.

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.

[Louis-Philippe Véronneau]

Post by Blair Noctis

Post by Alexandre Detiste
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

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.

[Étienne Mollier]

Post by Louis-Philippe Véronneau

Post by Blair Noctis

Post by Alexandre Detiste
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

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.

Cool! Thanks for the fix! :)

Post by Louis-Philippe Véronneau
When that happens, I'm planning on making a MBF.

Have a nice day, :)

[Louis-Philippe Véronneau]

Post by Blair Noctis

Post by Alexandre Detiste
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?

The idea of having these libraries around for Trixie (and to remove them
after the release) is to ease the 3.13 transition.

From my preliminary analysis, there are more than 600 packages that use
one of the stdlib that'll be removed in 3.13.

That is a lot of work and I doubt we'll have a successful transition
without this temporary measure.

[Matthias Klose]

Post by Louis-Philippe Véronneau

Post by Blair Noctis

Post by Alexandre Detiste
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?

The idea of having these libraries around for Trixie (and to remove them
after the release) is to ease the 3.13 transition.
From my preliminary analysis, there are more than 600 packages that use
one of the stdlib that'll be removed in 3.13.

There's also the option to remove packages from testing and/or unstable.
I assume, we'll see a lot of packages still using old modules getting
removed from testing, once 3.13 becomes the default. It's also an option
to remove those completely, if they are not maintained.

Post by Louis-Philippe Véronneau
That is a lot of work and I doubt we'll have a successful transition
without this temporary measure.

can we agree on a naming for the packaging, e.g.
python3-zombie-<module>, so that we make it clear, that people are using
obsolete code?

we do that for python3-zombie-imp already.

Matthias

[Louis-Philippe Véronneau]

Post by Matthias Klose

Post by Louis-Philippe Véronneau

Post by Blair Noctis

Post by Alexandre Detiste
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?

The idea of having these libraries around for Trixie (and to remove
them after the release) is to ease the 3.13 transition.
 From my preliminary analysis, there are more than 600 packages that
use one of the stdlib that'll be removed in 3.13.

There's also the option to remove packages from testing and/or unstable.
I assume, we'll see a lot of packages still using old modules getting
removed from testing, once 3.13 becomes the default. It's also an option
to remove those completely, if they are not maintained.

Post by Louis-Philippe Véronneau
That is a lot of work and I doubt we'll have a successful transition
without this temporary measure.

can we agree on a naming for the packaging, e.g. python3-zombie-
<module>, so that we make it clear, that people are using obsolete code?
we do that for python3-zombie-imp already.

I like this a lot and I support this naming scheme.

--
⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ ***@debian.org / veronneau.org
⠈⠳⣄

[Alexandre Detiste]

Post by Blair Noctis

Post by Alexandre Detiste
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.

Thank you, it gaves indeed better results.

Filed two bugs & uploaded pychess;
there's not soooo much to review for this one library;
(but we have like 20-something deprecated libraries in Py3.13)


This one is awesome ;-), it reminds of old time screen-scrapping
https://sources.debian.org/src/astrometry.net/0.95+dfsg-1/util/horizons.py/
No one will ever dare to rewrite this with another library.

---

What should we do for the new netmiko that vendors importlib wholesale
in next to-package release ?:
- simply paper over it in d/copyright
- unvendor & depends on python3-zombie-telnetlib for better tracability

https://github.com/ktbyers/netmiko/commit/b2700b56337dc7a04e6d8980e2a71eb4215e5d4e

Post by Blair Noctis
Please file bugreports/issues to ask the packages you care about to migrate.

I don't care for any of these packages but more for the distribution as a whole.
MBF with the new fixed Lintian tag is the way to go.

Greetings