[scl.org] Python3 (always latest) community SCL

[Nick Coghlan]

On Wed, May 3, 2017 at 9:44 PM, Tomas Orsava <torsava at redhat.com> wrote:
> On 05/03/2017 09:13 AM, Nick Coghlan wrote:
>>> On 04/11/2017 10:24 AM, Nick Coghlan wrote:
>> While I thought this sounded reasonable at the time, it turns out to
>> have a lot of problems in practice, as it makes it hard for developers
>> to say "I just want to run on a pre-built version of the latest
>> upstream Python". Instead, they have to choose between:
>>
>> * referring to python3.x in their own code, and having to update all
>> those references to switch to a new version
>> * keeping their "python3" references, and trusting that the originally
>> planned EPEL transitions will happen in a timely fashion
>
>
> I agree that it's not exactly seamless, you can make a single boolean macro
> in your spec file using which it will be switched to the alternative Python,
> so it shouldn't be a significant maintenance burden.

For the use cases I'm interested in, there's no application level spec
file - just a container definition or Ansible deployment script.

SCLs are really useful for those cases, since it's relatively
straightforward to ensure the SCL is enabled at the appropriate times,
while RPM macros aren't available.

>> And then regardless of the approach they choose, they have to rely on
>> either virtualenv or fiddling with the system level symlink to run
>> against an alternative Python 3 stack.
>
> If I may ask, what do you mean by fiddling with the system level symlink? I
> believe they can invoke `/usr/bin/python3.X` using the %{__python3_other}
> macro.

Choosing a stack other than the default one at runtime (rather than
when building an RPM). I'm not suggesting changing the symlink would
be a good idea, just pointing out it's basically the only option left
if you're not using either SCLs or a Python level venv and aren't
willing to qualify every Python 3 invocation with a specific minor
version.

>> That approach is then a lot closer to the traditional RPM update flow
>> from upstream->Fedora->RHEL->CentOS, just modified to be
>> upstream->SCLo->RHSCL->EPEL since there isn't a system Python 3 stack
>> in RHEL & CentOS.
>
> I do see the benefits of the added rolling SCL, though in my mind the
> benefits are lessened by the pre-existence of Python 3 in EPEL, and thus I'm
> not sure it's worth the added maintenance. However, that's only my personal
> reasoning.
>
> If we can find volunteers for the effort I'll be glad to lend a hand with
> the creation of the SCL.

I'd like to see this happen enough to volunteer to maintain it myself,
so I'll start working through the checklist that Honza posted :)

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Platform Engineering, Brisbane