[scl.org] Python "latest" SCLo

[Nick Coghlan]

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-b408f06ad89fd3a67686f755eafac7ce310ee081
> (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