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

Honza Horak hhorak at redhat.com
Wed Apr 26 15:47:07 UTC 2017

On 04/13/2017 04:27 PM, Tomas Orsava wrote:
> Hi!
> On 04/11/2017 10:24 AM, Nick Coghlan wrote:
>> I've been mulling this idea over for the past couple of weeks, and I'm
>> wondering if it might make sense to create a rolling "sclo-python3"
>> SCL, that's initially forked from
>> https://www.softwarecollections.org/en/scls/rhscl/rh-python35/, but
>> explicitly promises to rebase to new Python feature releases when they
>> come out.
>> So if people were happy to always run on the leading edge (even for
>> X.Y.0 releases), they could use "sclo-python3", but if they wanted to
>> stay on a particular X.Y release for a while, they would need to
>> switch to the downstream rh-pythonXY SCLs.
>> Remi, if I wanted to do that, where would I start?
>> https://github.com/sclorg-distgit is useful as a reference for
>> submitting changes to existing community SCLs, but it doesn't provide
>> any guidance on how to start a new one (and that info is also missing
>> from the wiki).
> It would be great to have a state-of-the-art Python in Enterprise Linux,
> but I think it would be better using the existing (though lacking
> maintenance) Python 3 in EPEL [0] mechanism.
> While installing and using SCLs isn't hard, I think an RPM packaged
> version is still easier for both maintenance and usage and people can
> have EPEL packages built against it as well. In addition the transition
> mechanism is smoother, as two Python versions are coexisting during the
> transition period, whereas the rolling SCL would just switch and
> everyone would have to immediately adjust.
> What would be the advantage of creating a rolling 'scl-python3'
> collection over the EPEL mechanism [1]?

I though I've already replied here, but obviously not.. One reason why 
rolling python3.x SCL might be better than EPEL is that some other 
projects within CentOS Build System might start using it, while EPEL 
packages are not generally usable there.. So, I'm not against if anyone 
would like to create such SCL, but I won't push on it either..


> [0] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
> [1] https://admin.fedoraproject.org/pkgdb/package/rpms/python34/
> All the best,
> Tomas
> _______________________________________________
> SCLorg mailing list
> SCLorg at redhat.com
> https://www.redhat.com/mailman/listinfo/sclorg

More information about the SCLorg mailing list