FPC ticket for building for multiple versions of a language stack?

[Nick Coghlan]

On 28 September 2015 at 17:18, John Dulaney <jdulaney at fedoraproject.org> wrote:
> ----------------------------------------
>> Date: Mon, 28 Sep 2015 15:18:00 +1000
>> Subject: FPC ticket for building for multiple versions of a language stack?
>> From: ncoghlan at gmail.com
>> To: env-and-stacks at lists.fedoraproject.org
>>
>> Hi folks,
>>
>> My Google-fu is failing me, so I'm asking to see if anyone else has
>> the relevant link: I recall seeing a proposal a while back (from
>> Slavek, IIRC) to support running a spec file multiple times with a
>> different target location each time (but still having a default
>> location used in a "normal" RPM build).
>>
>> This wasn't about SCLs, it was about situations like building for
>> python 2 + python 3 + pypy + jython, or for the multiple Python 3
>> stacks in EPEL. The general idea was that packaging for multiple
>> runtimes shouldn't be as difficult as it currently is.
>>
>> Cheers,
>> Nick.
>
>
> Well, why run it multiple times, and instead just set up your spec file
> to build different sub-packages against each stack you want to support,
> like what is already done for py2 and py3?

Because the status quo means that if we have (say) 5000 Python
packages, and we want to support a parallel Python stack for PyPy, we
have to modify 5000 spec files. Ditto for Jython and IronPython (and
don't forget to multiple by 2 for PyPy3, and eventually Jython3 and
IronPython3).

This doesn't make any sense when "<runtime> -m pip install --no-deps
<package_name>" works to install any Python package into the
appropriate location for the given runtime.

If we decouple the two operations and have the spec file merely say
"Here is how to install this module for a given Python runtime", then
we can separate out the packaging of the module for the default Python
runtime, and rebuilding it for alternate runtimes.

The ideal end state then becomes being able to ship all of the Python
packages with %check sections that pass with that runtime for every
Python runtime available in Fedora.

The alternative in the meantime is to just use Fedora to manage the
runtimes themselves, and use the Python specific module management
tooling on top of that, which is exactly what most developers are now
doing.

> Of course, I haven't seen what
> you are referring to, so I may be missing out on something brilliant.

Slavek's idea was to do this at the RPM level, by introducing loops
into spec files: http://rpm.org/ticket/883

My inclination is to favour a more SCL style approach, where the
definition of the runtimes to build for is defined at the distribution
level, rather than in the individual packages.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia