[Pulp-dev] To SCL or not to SCL
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
More information about the Pulp-dev