[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse-packaging
Subject:    Re: [opensuse-packaging] singlespec RFC: python3-only builds, %have_python, %skip_python
From:       Todd Rme <toddrme2178 () gmail ! com>
Date:       2017-06-14 16:14:17
Message-ID: CADb7s=sDKrbJgiDAiRPY7Q_AU44a2fJ7TZB1o1Kut_KMbBPKMA () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jun 13, 2017 at 10:52 AM, jan matejek <jmatejek@suse.com> wrote:
> Fellow Python packagers,
> 
> while trying to solve the issues surrounding python3-only singlespec builds, I \
> finally figured out that the OBS is not *at all* doing what I thought it was doing, \
> and everything is now lost forever 
> and now seriously.
> For various technical reasons that I will discuss at the end of this e-mail, using
> "%undefine have_python2" for removing python2 from the build set is not viable. I \
> will have to redesign the macros that are present in prjconf and use some other \
> method to accomplish the same. 
> The current WIP solution is as follows:
> 
> 1. %pythons macro will contain the build set, i.e., list of all flavors that we \
> build for. in Factory, "%pythons" will expand to "python2 python3".
> 
> 2. contents of %pythons will be conditional on %skip_python macros.
> If you "%define skip_python2 1" in the spec file, python2 will be removed from \
> %pythons. the "%skip_python" symbols should not be defined ANYWHERE ELSE BUT the \
> current spec file. For prjconf, it is more suitable to change contents of %pythons.
> 
> 3. %python_module will iterate over %pythons, through a crazy convoluted scheme \
> that Ruby is also using. 
> So for the end packager:
> 
> * if you want to build everything by distro defaults, nothing changes
> * if you want to *exclude* a particular flavor from the build, you "%define \
>                 skip_$flavor 1"
> * if you want to list build flavors explicitly, you can redefine %pythons \
> themselves: %define pythons python2 jython2 pypy3
> * you can BuildRequire: %pythons, because %pythons will come from prjconf
> 
> For prjconf, we need:
> 
> * %pythons python2 python3
> (This is an opportunity to mess things up, because the *last* item in %pythons \
> actually specifies, through a side effect, the "default" python that overwrites \
> conflicting files. If you specify "python3 python2" and then "%python3_only \
> /usr/bin/foo", the /usr/bin/foo will actually be a python2 version.
> OTOH, this allows per-package customization of the default, and python-rpm-macros \
> will contain the canonical order.)
> * the set of python_module expanders
> 
> Installed Python packages will still define %have_$flavor macros, so you can switch \
> build options based on which pythons are present. However, this is no longer tied \
> to the build set: especially in a local build, you could get %have_python2 true but \
> not actually build it for Python2. That shouldn't matter in practice.
> 
> comments, questions, thoughts?
> 
> regards
> m.
> 
> -----
> 
> p.s.: For those interested, here are the technical details.
> 
> The original intention was that if you wanted to skip a particular build \
> requirement, you could do: %undefine have_python2
> This would remove "python2" from the build set and you wouldn't get any \
> python2-related wording in the spec file.
> 
> One problem with this approach is that definitions in RPM are placed on a stack and \
> so you need to %undefine as many times as you %defined. Hence the current bug where \
> you need to %undefine have_python2 twice (at least).
> 
> Another is that OBS doesn't understand %undefine at all! So this declaration \
> actually doesn't do anything, and your %python_modules still install *all* python \
> versions. The double-%undefine is then needed because you get one have_python2 from \
> prjconf and another from the installed python2 package. 
> The new solution doesn't rely on undefines, and redefinitions work about as well as \
> we would expect.

Overall this seems good.

The only issue with the current approach from what I can see is that
it seems you can only add new pythons by completely replacing the
default set. There doesn't seem to be a way to add individual
non-default pythons while otherwise keeping the project defaults.
This would be important for pypy or jython, where I think we would
want to keep it disabled by default and only explicitly turn it on in
a per-package basis. So perhaps a "%add_python foo" macro that adds
"foo" to "%pythons" if it isn't already there.  Perhaps by default it
adds it to the beginning of the list if it isn't already there, while
"%add_python foo 1" will always add it to the end of the list
(promoting it to being the "primary" python version, even if it is
already in "%pythons" at a different position).
-- 
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org


[prev in list] [next in list] [prev in thread] [next in thread]