<div dir="ltr"><div dir="ltr">On Fri, Mar 19, 2021 at 11:15 AM Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I've been paged out for a while, but previously looked after the<br>
tahoe-lafs package in pkgsrc, and am again because 2.7-only packages are<br>
causing extra maintenance burden and hence there is pressure to outright<br>
remove them. Some of this may be well known, but I'll type more and<br>
assume less.<br></blockquote><div><br></div><div>Hello Greg,</div><div><br></div><div>Thanks for reaching out and thanks for the excellent detail in this email. The strategies / tradeoffs / challenges you outlined all seem to make sense to me.</div><div><br></div><div>I think everyone who uses Tahoe is increasingly feeling the pressure from the gradual wind-down of the Python 2.7 ecosystem. The good news is that the Python 3 porting effort is quite far along - modules that constitute over 75% of the lines of Tahoe have been ported and many other modules are partially ported. It's hard to estimate when this will be done but I am <b>hopeful</b> that we are looking at a Python 3-supporting release sometime this Spring. The effort has committed resources behind it so there's no reason to think we won't be able to get over the finish line.</div><div><br></div><div>I'm curious about whether you think having magic-folder as an optional dependency would be beneficial for your packaging efforts or the users of those packages <i>after</i> the Python 3 port is complete, or if this is mostly/entirely about working around the increasingly constrained state of Python 2.7 libraries?</div><div><br></div><div>Regarding txtorcon, it is an optional dependency that enables Tahoe to run over Tor.</div><div><br></div><div>Thanks for getting in touch,</div><div>Jean-Paul</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I'm assuming that it's important to the project to be in packaging<br>
systems, so people can "${pkgfoo} install tahoe-lafs", for their<br>
preferred value of pkgfoo, rather than having to engage with the<br>
underlying language mechanims, not have automatic updates, and not have<br>
automatic warnings of CVEs. (Similarly, I'm assuming that while the<br>
tahoe-lafs developers almost certainly don't use a packaging system for<br>
tahoe, I would expect that they do for 95%+ of the other software they<br>
run.)<br>
<br>
I gather there is progress on a python 3 version from the trac roadmap,<br>
but it's hard for me to tell what kind of timeline there is. I realize<br>
everyone understands that this is necessary.<br>
<br>
>From the packaging viewpoint (which I realize you may not be super<br>
familiar with), the two basic problems are:<br>
<br>
python2.7 is EOL and not receiving security updates, so its continued<br>
presence is uncomfortable.<br>
<br>
Many python packages are releasing new versions that drop python2<br>
support, even though other programs in the open source world that<br>
depend on those packages are still python2 only. The old versions do<br>
not receive security updates, and many other programs and modules<br>
depend on updated versions.<br>
<br>
So, early on the strategy was to defer updates to packages if an update<br>
would break some 2.7 only reverse dependency (thing that depends on the<br>
package, to use the Debian term). That was only ok for a few months,<br>
and now our strategy is a combination of:<br>
<br>
Question the continued presence of things that are 2.7 only, in that<br>
if they are unmaintained, don't have users, etc. it may be just as<br>
well to rm them.<br>
<br>
Introduce versioned dependencies, where when building for 2.7, choose<br>
the last 2.7-capable (and thus no longer maintained) version of a<br>
python package, and for 3.x, choose the maintained version. Add those<br>
old versions as necessary, when the work to do so seems worthwhile<br>
depending on what's being kept usable.<br>
<br>
and at some point this will be untenable, and programs that don't<br>
support 3 will just be removed from the packaging system.<br>
<br>
(Debian is also heading down the path of removing python2 and has<br>
already removed tahoe-lafs.<br>
<br>
<a href="https://tracker.debian.org/pkg/tahoe-lafs" rel="noreferrer" target="_blank">https://tracker.debian.org/pkg/tahoe-lafs</a><br>
<a href="https://lists.debian.org/debian-python/2019/07/msg00080.html" rel="noreferrer" target="_blank">https://lists.debian.org/debian-python/2019/07/msg00080.html</a><br>
<a href="https://www.linuxcompatible.org/story/update-on-python-2-removal-in-debian-sid-bullseye/" rel="noreferrer" target="_blank">https://www.linuxcompatible.org/story/update-on-python-2-removal-in-debian-sid-bullseye/</a><br>
<a href="https://wiki.debian.org/Python/2Removal" rel="noreferrer" target="_blank">https://wiki.debian.org/Python/2Removal</a><br>
)<br>
<br>
pkgsrc was at 1.12.1 (old I know) and I have done a trial update to<br>
1.15.0. However, that ran into a number of problems.<br>
<br>
magic-wormhole has a lot of dependencies and a few I have to add<br>
(which is fine). However, quite a number of them have current<br>
releases which are 3.x only, so building a py27-magic-wormhole would<br>
require adding a bunch of versioned dependencies.<br>
<br>
There appear to be similar issues with tahoe-lafs itself requiring<br>
2.7-supporting and hence old, unmaintained versions of a few python<br>
packages (autobahn, txtorcon). Perhaps txtorcon is actually optional;<br>
I'm having enough other problems that it's hard to tell.<br>
<br>
It would help pkgsrc to update tahoe-lafs to 1.15.0, both for the usual<br>
notion of users having a recent release, and because a number of really<br>
old dependencies are no longer used (eg., py-crypto which we've patched<br>
to use cryptodome instead). One thing that would help that is if<br>
magic-wormhole were not a hard requirement, and was only needed if not<br>
tried to use a feature that uses it. I don't know how hard that is, and<br>
if that would really get us over the line to 1.15.x in pkgsrc. And if a<br>
3.x release is going to happen in the next 30 days, there's of course no<br>
point.<br>
<br>
I tried to just comment it out, very hackily, and the built tahoe runs<br>
enough to print the command help, as long as I have hand-installed an<br>
old py27-autobahn.<br>
<br>
<br>
My todo list is huge, and to be honest this isn't high on it, but I<br>
wanted to let you know how this is heading, as I'm not at all sure how<br>
the project views the situation.<br>
<br>
I'd like to hear how the project sees this.<br>
<br>
<br>
Greg<br>
_______________________________________________<br>
tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org" target="_blank">tahoe-dev@tahoe-lafs.org</a><br>
<a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" rel="noreferrer" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
</blockquote></div></div>