[scl.org] Python "latest" SCLo

[Davis, Daniel (NIH/NLM) [C]]

I will be able to provide testing, and I'll follow along.

Your note about how fast it will move really points out that we need to learn how to do it ourselves, because we will want to move both fast and slow, at times.

-----Original Message-----
From: Nick Coghlan [mailto:ncoghlan at redhat.com] 
Sent: Tuesday, July 11, 2017 4:45 AM
To: Davis, Daniel (NIH/NLM) [C] <daniel.davis at nih.gov>
Cc: sclorg at redhat.com
Subject: Re: [scl.org] Python "latest" SCLo

On Mon, Jul 3, 2017 at 3:47 PM, Nick Coghlan <ncoghlan at redhat.com> wrote:
> On Fri, Jun 30, 2017 at 1:24 AM, Davis, Daniel (NIH/NLM) [C] 
> <daniel.davis at nih.gov> wrote:
>> I’ve been lurking on this list for a while, and I wanted to bring myself up
>> to date.   I noticed some talk of a community SCL for a “latest” Python,
>> which would be a non-patched pure build of Python that is kept up-to-date by
>> the community.   Where is that at?   Who is leading it?
>
> That would be me, but it stalled while I was working on some Python
> 3.7 changes. Happily though, I have some time to spend on 
> bootstrapping the "rolling Python" SCL this week, so I'm going to 
> start working through the list of tasks at
> https://wiki.centos.org/SpecialInterestGroup/SCLo#head-b408f06ad89fd3a
> 67686f755eafac7ce310ee081 (using the rh-python35 collection as a 
> starting point)

So I finally started working on the technical aspects of this, and as near as I can figure out, what I'll need to do is:

1. Create a new sclo-python metapackage, using https://github.com/sclorg-distgit/rh-python35/tree/master as a starting point 2. For now, just create a `sig-sclo7-sclo-python` branch (we can look at an sclo6 branch once 7 is working) 3. Edit https://github.com/ncoghlan/sclo-python/tree/sig-sclo7-sclo-python
for the rh-python35 -> sclo-python name change 4. Start doing some test builds in COPR as per https://www.softwarecollections.org/en/docs/

In parallel with that:

4. Submit a buildsys request for an sclo-python tag that's similar to the existing rh-python35 one (akin to
https://bugs.centos.org/view.php?id=9661 ) 5. Figure out what, if anything, needs to be done in terms of adding relevant branches to the other Python repos on https://github.com/sclorg-distgit 6. Actually start building real SCLs in the CentOS build system for publication to softwarecollections.org

Cheers,
Nick.

P.S. Additional next step: provide feedback to the Fedora Modularity group on which aspects of this strike me as being the most annoyingly tedious, and what could potentially be done to make distro-submodule-based SCL definitions and updates less time consuming than the current process based directly on RPMs and dist-git :)


--
Nick Coghlan
Red Hat Platform Engineering, Brisbane