On 2.3.2018 11:25, Pavel Raiskup wrote:

On Friday, March 2, 2018 10:36:36 AM CET Miro Hrončok wrote:

...

I've prepared a draft for Python packaging that introduces some new macros that should ease packaging for Fedoras, EPELs and even potential new RHELs, when it comes to python stacks.

I don't do much ifs in specfiles and prefer to leverage git branches for this, so I don't know what bothers you most. The proposal with example spec file is at:

https://fedoraproject.org/wiki/User:Churchyard/Packaging:PythonMustMayMacros [..snip..] Could you please provide feedback? Ask questions?

What's the real usecase for *_must?

This tells you that according to the guidelines for given distro, if upstream supports this python version, you MUST package for it. Some packages might want to only package their Python library for the stacks where it's required.

Why the py2_must is not defined for epel7 and epel6?

Because there is no such guideline. It is completely OK to package for python3 only on EPELs.

I always only needed to see whether (a) python2 runtime is available, (b) python3 is available. So more readable and understandable approach (to me) would be to have only the %pyX_may (or %py3_available). But I'm probably not experienced enough, so I'm only curious :-).

For that, yes. here may == available. We can discuss the naming if it sounds weird.

E.g. last time (argparse-manpage) I went with:

%if 0%{?fedora} %bcond_without python2 %bcond_without python3 %else %if 0%{?rhel} > 7 %bcond_with python2 %bcond_without python3 %else %bcond_without python2 %bcond_with python3 %endif %endif

Which allows me to do things like:

%if %{with python2} .... %endif

Or:

BuildRequires: %{?with_python3:foo} %{?with_python2:bar}

.. and which brings the convenient --with{,out}-python{2,3} options for custom re-builds. Could we have something similar in the draft, too?

We can definitively make those with statemetns, however we cannot make it with_python2 and with_python3, because we might destroy current specfiles with that. So we would need to have:

%if %{with python2_must} .... %endif

Or:

BuildRequires: %{?with_python3_may:foo} %{?with_python2_must:bar}

And specifying those on the command line would be rather unreadable. What does --with-python2-may even mean?

You can always define your with_python2 based on values of py2_may, py2_must and fedora version.

On 2.3.2018 11:50, Pavel Raiskup wrote:

On Friday, March 2, 2018 11:32:40 AM CET Miro Hrončok wrote:

...

On 2.3.2018 11:25, Pavel Raiskup wrote:

...

On Friday, March 2, 2018 10:36:36 AM CET Miro Hrončok wrote:

...

I've prepared a draft for Python packaging that introduces some new macros that should ease packaging for Fedoras, EPELs and even potential new RHELs, when it comes to python stacks.

I don't do much ifs in specfiles and prefer to leverage git branches for this, so I don't know what bothers you most. The proposal with example spec file is at:

https://fedoraproject.org/wiki/User:Churchyard/Packaging:PythonMustMayMacros [..snip..] Could you please provide feedback? Ask questions?

What's the real usecase for *_must?

This tells you that according to the guidelines for given distro, if upstream supports this python version, you MUST package for it. Some packages might want to only package their Python library for the stacks where it's required.

FWIW, I don't think macros should be used to _enforce_ guidelines (should be rather convenient things which everyone loves to use). But no problem, as long as I don't have to use that. Just saying that it might be a bit confusing when reading the (draft) wiki...

They don't enforce anything. They just make it possible to get the value defined by the guideline in a technical manner and do with the value whatever you please. It's still up to the packager to decide what to do when py3_must is 1 or when it's not.

If the wiki is confusing, I can try to reword the description. However I'm afraid everybody will just jump to the table anyway.

...

...

Why the py2_must is not defined for epel7 and epel6?

Because there is no such guideline. It is completely OK to package for python3 only on EPELs.

...

I always only needed to see whether (a) python2 runtime is available, (b) python3 is available. So more readable and understandable approach (to me) would be to have only the %pyX_may (or %py3_available). But I'm probably not experienced enough, so I'm only curious :-).

For that, yes. here may == available. We can discuss the naming if it sounds weird.

...

E.g. last time (argparse-manpage) I went with:

%if 0%{?fedora}
  %bcond_without python2
  %bcond_without python3
%else
  %if 0%{?rhel} > 7
    %bcond_with    python2
    %bcond_without python3
  %else
    %bcond_without python2
    %bcond_with    python3
  %endif
%endif

Which allows me to do things like:

%if %{with python2}
  ....
%endif

Or:

BuildRequires: %{?with_python3:foo} %{?with_python2:bar}

.. and which brings the convenient --with{,out}-python{2,3} options for custom re-builds. Could we have something similar in the draft, too?

We can definitively make those with statemetns, however we cannot make it with_python2 and with_python3, because we might destroy current specfiles with that. So we would need to have:

 %if %{with python2_must}
   ....
 %endif

Or:

 BuildRequires: %{?with_python3_may:foo} %{?with_python2_must:bar}

And specifying those on the command line would be rather unreadable. What does --with-python2-may even mean?

--with-py3 or --with-py3-available doesn't soudd that bad, but ..

I wouldn't worry about existing spec files.. and I would stick with --with-python2 (and friends). Existing spec files should not depend on the distro-default value, since no distro so far defined that; which means that whatever value is defined in spec file will _just_ override the new system default. For the few remaining packages (are there any?), well, there go proven packagers...?

I hear you. I like the idea Petr just sent to python-devel, so lets continue from there.

On 2.3.2018 16:23, Richard W.M. Jones wrote:

On Fri, Mar 02, 2018 at 10:36:36AM +0100, Miro Hrončok wrote:

...

Hello Pythonistas,

I've prepared a draft for Python packaging that introduces some new macros that should ease packaging for Fedoras, EPELs and even potential new RHELs, when it comes to python stacks.

I don't do much ifs in specfiles and prefer to leverage git branches for this, so I don't know what bothers you most. The proposal with example spec file is at:

https://fedoraproject.org/wiki/User:Churchyard/Packaging:PythonMustMayMacros

All you have to do to test it, is add the following block to your spec (that won't be needed once this is actually implemented):

 %if 0%{?fedora}
 %global py3_must 1
 %global py3_may 1
 %global py2_may 1
 %endif

 %if 0%{?rhel} &&  0%{?rhel} <= 7
 %global py3_may 1
 %global py2_may 1
 %endif

 %if 0%{?rhel} > 7
 ... (use your best judgment here)
 %endif

Could you please provide feedback? Ask questions?

There is a note at the bottom of the draft about how you could possibly start dropping Python 2 subpackages from Fedora.

Thanks for doing this, it is much needed.

I'm not really convinced by the *_may macros. If I've gone to the trouble of getting the subpackage snippets correct for both of python2 & python3, why wouldn't I just enable them in all possible situations? I can't see a situation where we've got possible subpackages but we don't want to build them (except for where python2/3 is not available in the distro and so they can't be built).

You might want to remove python2 subpackage from Fedora because it's not needed by anything. Ultimately, removing leaf python2 subpackages is also our goal. If we only provide a macro that says "it is possible", people will keep using it until judgment day.