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?

Why the py2_must is not defined for epel7 and epel6?

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 :-).

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?

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...

>> 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...?

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).