On 05/03/2017 02:35 PM, Nick Coghlan wrote:
On Wed, May 3, 2017 at 9:44 PM, Tomas Orsava <tors...@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.
_______________________________________________
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg
