[arch-dev-public] Add active Python versions to the repos

[Filipe Laíns]

On Sat, 2020-11-21 at 20:24 -0500, Eli Schwartz via arch-dev-public wrote:
> Your analysis is correct, it is indeed hell. I'm not sure why that is an
> argument in favor of doing even more of it though.
> 
> Now, if you were proposing to get rid of some of this, I could get
> behind that.

It was not an analysis, "hell" was an used here as an idiom.

> > even Python.
> 
> I don't know if maybe you've missed the fact that we've spent like a
> year now aggressively upgrading or removing leaf packages depending on
> python2 in search of that glorious Promised Future where we can finally
> remove the python2 package itself?

I did not miss that. I absolutely want to see the python2 modules removed, not
_necessarily_ the python2 interpreter.

> And we're doing that even for a major incompatible release that most
> people argue is actually a different language.
> 
> I'm not sure how this suddenly became an argument to package a ton of
> point releases that aren't even incompatible.

Except they are... Python does not follow semver, only patch releases are
supposed to be compatible. They do try to keep breakage to a minimum, but it
definitely exists. One very obvious example is the introduction of "async" and
"await" as reserved keywords. There are a bunch of other backwards incompatible
changes, so yes, they are incompatible releases, to the point you could call
them different languages.

> > I don't think having people opening bugs because they are
> > deliberately using an older version of Python is a big problem. It
> > hasn't been for any of the other languages, I don't think it will be
> > here.
> > I think this is an hypothetical that doesn't really materialize into
> > reality.
> 
> You're proposing something far beyond the scope of what we do for other
> languages, and ignoring that for other languages we only do it if driven
> to in desperation because another official repository package depends on it.
> 
> We don't introduce leaf packages of ancient versions of currently
> packaged interpreters just for fun. I don't even think anyone else does
> that either.

That was not of the point of me bringing up other languages. The whole point of
me bringing up other languages was to show that Andreas' concern is unlikely to
materialize into reality.

> > > It's sad enough we still have python2 and gtk2 around. To have gcc9
> > > around and other duplicates is not what I want to see growing in
> > > Arch. 
> > 
> > What you call sad I call a bad UX. Why do we need to force users to
> > compile active releases of the Python interpreters themselves, which
> > can take a long time if they are building with optimization, or to
> > resort to pre-built repos with much lower security standards than us,
> > when there are people willing to maintain them?
> > 
> > I can't understand how it's sad to help out users by not forcing them
> > to resort the sort of things I mentioned above, as long as we are not
> > struggling to do so. I like helping people, that's why I am a packager,
> > that is the opposite of sad for me, so I really can't understand this.
> 
> I have... no idea what the problem is supposed to be here? I'm
> desperately trying to understand what the actual point of your proposal is.
> 
> You want to package old versions of the python3 interpreter "but not
> modules", because "people would like to use it for tox".

People can use it tox or to create virtual environments directly. The main point
of the proposal is that people have use for the old interpreters and I would
like to provide them.

> Old versions of stuff that people need for who knows what weird reason
> is *the textbook reason* why the AUR exists. How long it takes to
> compile stuff in the AUR is not our problem, and we don't have a
> rationale to upload gcc-{4,5,6,7,8,9} because actual users need to use a
> lot of diverse compilers "to test that it still works on really old
> compilers".

AFAIK, the textbook reason why the AUR exists is to provide software that isn't
in the official repos. It being older versions should be completely incidental,
but not the "textbook reason".

> Likewise, if people want to test support for old versions of python3,
> they have options which don't involve uploading trash into [community].

I like how you refereed to the currently active Python releases as "trash", will
keep that in mind.

> - Do what normal people do, and build AUR packages they need
> - Ask FFY00 to provide signed repos
> - Use travis CI, which doesn't use distro packages but provides a
>   diverse set of hand-compiled python versions, which is apparently some
>   kind of gold standard for doing regression testing on lots of
>   different python releases ;)
> - Use pyenv
> 
> Apparently none of these are viable options in your mind, and the most
> Arch-like of them, option #1 "use the AUR" you believe to be problematic
> because it takes a long time to build with optimizations... even though
> you yourself said those packages don't enable optimizations and don't
> take a long time???
> 
> (If you're using python-$old exclusively for regression tests in tox,
> you don't need a super optimized version.)

Tests can take a long time to run, multiply that by the interpreters you need to
run them against. But that is only part of the reason.

> > > I don't want to see our distribution transformed into another Debian.
> > 
> > That is not what is happening.
> 
> Yeah, even Debian doesn't do this. Travis-ci.com does, though.
> 
> I don't see any reason why [community] needs to grow to support the
> needs of exclusively Continuous Integration testsuite matrixes.

I agree, it doesn't need to grow support for this specific need. What I think it
should grow support to is software that is being actively missed by arch users,
which in this case are the Python interpreters for active Python releases.

I don't understand what are the drawbacks of this. Having more packages in the
repos, I guess?

As long as there is someone willing to maintain the packages, why would we block
it? I doesn't really have any effect on the rest of the people. If the person
start having trouble maintaining them, they can be dropped. It doesn't affect
you and helps other people.

Cheers,
Filipe Laíns
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20201122/99846c40/attachment.sig>