Apps using default Python in Fedora vs. EPEL

[Toshio Kuratomi]

On Wed, Jan 28, 2015 at 11:59:01AM -0500, Bohuslav Kabrda wrote:
> ----- Original Message -----
> > On Tue, Jan 27, 2015 at 06:26:26AM -0500, Bohuslav Kabrda wrote:
> > > 
> > > Current state:
> > > - Up until F21, maintainers were encouraged to build applications with
> > > Python 2, but weren't discouraged from building with Python 3.
> > 
> > Note -- this isn't quite right.  If an application could run with either
> > python2 or python3 maintainers in F21 and below were supposed to have the
> > app run with python2.  F22 is supposed to flip this so that maintainers are
> > supposed make these packages run with python3 instead of python2.
> 
> I guess that I interpreted it my way since I didn't see any "must" in there... But ok, thanks for the clarification :)
> 
Yeah -- a product of Fedora Guidelines being written by different people at
different times.  We don't have strict RFC-like usage of should and may in
most places. (must is usually unambiguous as to being a directive and
a bolded "should", "must", or "may" has precise meaning.  Other uses (or
simple lack of any of those terms) leaves the question of how strict
a question that would have to go back to the FPC to figure out what they
meant in the past or what they want it to mean in the present day.)

> > > - This means that packagers will be able to use the unversioned macros
> > > throughout their specfile. Requires and BuildRequires will look like this:
> > > 
> > > Requires:     %{default_python}-flask
> > > BuildRequires %{default_python}-setuptools
> > > 
> > > Note: since BuildRequires need to be expanded in the minimal buildroot,
> > > it's necessary to define the %default_python macro in the specfile. Other
> > > way would be to define it in a macro file that would be added to the
> > > minimal buildroot, but that's neither very likely nor very nice :)
> > > 
> > Have you talked to dennis?  We've added packages to the minimal BuildRoot
> > many times before in order to enable macro files.  Not so problematic if
> > it's only one macro, though.
> 
> I will. Do you have any idea who I should talk to regarding EPEL? Is it also Dennis?
>
Also dennis.  Rel-eng is growing as a group so you could also put in
a ticket/go to one of their weekly meetings but Dennis is probably still the
one that knows the most about koji and buildroots.

> 
> > > 
> > > I think this solution makes sense for *applications* that need to be built
> > > both in Fedora and in EPEL. Note that it'd also align with my EPEL-python3
> > > proposal [1], in case such an app was to be moved to python3X in EPEL
> > > (%default_python would just be redefined to "python3X"). I also think that
> > > this approach should never be allowed for packaging "libraries", e.g.
> > > packages that have python-foo and python3-foo subpackages.
> > > 
> > > Thoughts?
> > 
> > If we were to use different macro names instead of overwriting currently
> > well known ones I think this has merit.
> 
> For me, introducing yet another set of macros is unnecessary. I think that it'd introduce a long(-ish) new part of guidelines that'll make them even more complicated than they are right now (compared to one new macro function and rules on how/when to use it).
>
Nick's breakdown of the three desired states seems like a non-complex way to
organize things.  And explicit being a good thing is also a winner for me.
In addition to my original arguments that bashing existing macro names in
some spec files but not in all of them is a bad thing to force packagers to
have to deal with.

tangentially, when speaking about long-ish, though, could we use something
shorter than default_python?  Maybe syspython to follow Nick's usage of
"System Python"?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/python-devel/attachments/20150128/be78088a/attachment.sig>