12:18 a.m.
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.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
2:18 a.m.
----------------------------------------
Date: Mon, 28 Sep 2015 15:18:00 +1000
Subject: FPC ticket for building for multiple versions of a language stack?
From: ncoghlan(a)gmail.com
To: env-and-stacks(a)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? Of course, I haven't seen what
you are referring to, so I may be missing out on something brilliant.
John.
3:36 a.m.
On 28 September 2015 at 17:18, John Dulaney <jdulaney(a)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(a)gmail.com
> To: env-and-stacks(a)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(a)gmail.com | Brisbane, Australia
9:10 a.m.
On 09/29/2015 02:36 AM, Nick Coghlan wrote:
On 28 September 2015 at 17:18, John Dulaney
<jdulaney(a)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(a)gmail.com
>> To: env-and-stacks(a)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.
We're working on something somewhat similar here:
https://fedorahosted.org/fpc/ticket/567
The problem I have with at the moment is trying to automatically
generate the proper %files sections. Perhaps if the install could
generate a manifest.
But yeah, the SCL/distribution approach has a fair amount of appeal as
well, as long as the proper namespacing is done which gets tricky. I
had an idea a while back about somehow having different repos get put
into different namespaces automatically which I still think would be
worth pursuing.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
1:21 a.m.
On 30 September 2015 at 00:10, Orion Poplawski <orion(a)cora.nwra.com> wrote:
On 09/29/2015 02:36 AM, Nick Coghlan wrote:
> 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.
We're working on something somewhat similar here:
https://fedorahosted.org/fpc/ticket/567
The problem I have with at the moment is trying to automatically generate
the proper %files sections. Perhaps if the install could generate a
manifest.
If you add the relevant pip module to the BuildRequires and use
"<target_python> -m pip install" to do the installation (rather than
plain distutils or setuptools), you'll get a full manifest as a CSV as
described in https://www.python.org/dev/peps/pep-0376/#record
Passing "--record <filename>" to install will also do this, although
I'm not sure of the format in that case.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
2:49 a.m.
----------------------------------------
Date: Wed, 30 Sep 2015 16:21:28 +1000
Subject: Re: FPC ticket for building for multiple versions of a language stack?
From: ncoghlan(a)gmail.com
To: env-and-stacks(a)lists.fedoraproject.org
On 30 September 2015 at 00:10, Orion Poplawski <orion(a)cora.nwra.com> wrote:
> On 09/29/2015 02:36 AM, Nick Coghlan wrote:
>> 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.
>
> We're working on something somewhat similar here:
> https://fedorahosted.org/fpc/ticket/567
>
> The problem I have with at the moment is trying to automatically generate
> the proper %files sections. Perhaps if the install could generate a
> manifest.
If you add the relevant pip module to the BuildRequires and use
"<target_python> -m pip install" to do the installation (rather than
plain distutils or setuptools), you'll get a full manifest as a CSV as
described in https://www.python.org/dev/peps/pep-0376/#record
Passing "--record <filename>" to install will also do this, although
I'm not sure of the format in that case.
Cheers,
Nick.
This gives you a flat text file with a list of installed files, one per line.
John.
3:02 a.m.
----- Original Message -----
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.
Hey Nick,
it was actually RPM ticket, not FPC one: http://rpm.org/ticket/883
My idea was actually only running the build once and have functionality to dynamically
generate arbitrary number of subpackages during the build. I think it was you who
commented on that idea with a thought that we could have one specfile and build it
multiple times, perhaps with a macro defined to different values.
Slavek
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
3141
days inactive
3143
days old
env-and-stacks@lists.fedoraproject.org
6 comments
4 participants
participants (4)
-
Bohuslav Kabrda -
John Dulaney -
Nick Coghlan -
Orion Poplawski