[Pulp-dev] To SCL or not to SCL

Brian Bouterse bbouters at redhat.com
Mon Oct 3 16:11:17 UTC 2016

This sounds like a great idea. We talked over this question some last 
week and here is my from-memory summary.

- Pulp 3 will be compatible with Python 3.4 and 3.5
- We want travis and pulp-smash to test Pulp 3 with both Python 3.4 and 3.5
- For EL7 we will use SCLs to provide Python 3.5
- Current Fedoras already have Python 3.5

The thinking of keeping the Python 3.4 compatibility is that it would 
allow us to the SCL on EL6 if we have to. I believe the newest SCL for 
EL6 is 3.4. If we formally decide that EL6 won't be supported by Pulp 3 
then we can drop the Python 3.4 support at that time also.

Please correct me if others came away with different perceptions.


On 09/23/2016 03:21 PM, Patrick Creech wrote:
> After some research into how to package for software collections, it does look feesible to utilize
> them for pulp 3.  The main issue will be the fact that yes, we do have to package some new
> dependencies to utilize software collections instead.  While that statement initially appears loaded
> with a lot of work to do, in reality it does seem rather manageable.
> There are utilities out there to do things, like convert pypi packages to spec files, and to convert
> spec files to scl spec files.  We can take advatage of these utilities (and potentially help improve
> them) to automate the dependency workflow from pypi -> spec -> scl with what appears to be a rather
> good degree of confidence.
> The primary benifit of this, in my mind, is the ability to work with the latest upstream packages,
> and repackage them in a format usable in Software collections, freeing us from being locked in to
> what's available in the EL7 repos.  There is precedence for this, as foreman appears to do this
> already with their ruby dependencies.  They have their own "tfm" software collection group (from
> what I can tell).
> This might seem daunting on the surface, but I belive this will become a net positive for us as a
> whole. If we didn't go the software collections route, there will still be additional work needed to
> ensure our code would be python 2.7 AND 3.5 compatible, with extra care needing to be practiced by
> everyone to achieve it.  Along with potentially subtle differences in our dependency versions.
> Also, we currently build our dependencies that are needed in el6/el7/f2x already, and serve them up,
> sometimes needing work to ensure different versions work where needed.  Since pulp 3 is dropping
> el6, we can possibly aligning on fedora versions and simplify our dependency manangement needs
> enough to open up ample time to do this, helping us align with the "Upstream First" mentality
> At this point, I believe a proof of concept will need to be developed to figure out exactly what
> this will look like, but I am becoming increasingly optimistic that this is achieveable.  There will
> be some investment needed up front, but I'm confident it will pay off later.
> Starting now, I will be developing this proof of concept, focusing on getting a demo django app
> working, as well as a simple demo celery app.  While the initial investigation has proven
> optimistic, it will be nice to have some real world answers here and a picture of what this really
> looks like.
> Questions?  Thoughts?  Concerns?
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev

More information about the Pulp-dev mailing list