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

[Eli Schwartz]

On 11/21/20 11:59 AM, Filipe Laíns via arch-dev-public wrote:
> On Sat, 2020-11-21 at 16:58 +0100, Andreas Radke via arch-dev-public
> wrote:
>> Am Sat, 21 Nov 2020 14:34:24 +0000
>> schrieb Filipe Laíns via arch-dev-public
>> <arch-dev-public at archlinux.org>:
>>
>>
>>> Does anyone have any big issue with this? What are your thoughts?
>>>
>>> [1] https://www.python.org/downloads/
>>>
>>> Cheers,
>>> Filipe Laíns
>>
>> -1
>>
>> Arch is yours. Whoever needs more and older releases on the system -
>> just do it yourself! In the past we said "use abs and AUR - Arch is
>> the base to make it your own".
> 
> This argument can be used to deny adding any package to the repos. You
> need this library, tool, etc.? Just add it yourself.
> 
> Why are we packaging software that is used by far less people but we
> can't package these Python interpreters which are being actively missed
> by people?
> 
>> I don't want to see users raising bugs that something doesn't work
>> with an older version of python. And I don't want to see these
>> requests
>> pop up every now and then to add even more stuff in different
>> versions.
> 
> We already have multiple versions of Java, Ruby, Javascript, etc. hell,

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.

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

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.

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

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

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

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

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

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

-- 
Eli Schwartz
Bug Wrangler and Trusted User
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x84818A6819AF4A9B.asc
Type: application/pgp-keys
Size: 21716 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20201121/be87bd20/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20201121/be87bd20/attachment-0001.sig>