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

[Tomas Orsava]

On 05/03/2017 02:35 PM, Nick Coghlan wrote:
> 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 :)

In that case: Godspeed! And do contact me if I can help you with 
building of the collection!

All the best,
Tomas

>
> Cheers,
> Nick.
>