[Freeipa-devel] [PATCH] 0749 Package ipapython, ipalib, ipaplatform, ipatests for Python 3

[Petr Viktorin]

On 11/26/2015 11:52 AM, Jan Cholasta wrote:
> Hi,
> 
> On 6.11.2015 13:07, Petr Viktorin wrote:
>> Hello,
>> The Python 3 port is not 100% done, but I think the time has come to
>> start packaging the py3 bits. This will make it easier to plug into CI.
>>
>> The existing Python 2 packages should not change, except I've added
>> "freeipa-common" with files that aren't Python-specific.
>>
>> The new packages follow Fedora's Python guidelines a bit better. The
>> main thing is the names: python3-ipalib, python3-ipatests,
>> python3-ipap11helper.
>> The pure-Python ones are built as noarch.
>>
>>
>> The Makefiles are reorganized a bit, but they don't support building for
>> both py versions at once -- you need to do `make` followed by `make
>> PYTHON=/usr/bin/python3`. (The latter currently only works in the
>> directories that are ported so far, though.)
> 
> Thanks for the patch.
> 
> 
> 1) The freeipa-common subpackage is not necessary: /etc/ipa/dnssec
> should be owned by freeipa-server and everything else in /etc/ipa
> currently owned by freeipa-python should be owned by freeipa-client.

If the common files are in freeipa-server or freeipa-client, then the
Python 3 packages would need to depend on those. I'd like to avoid that.


> This should be a separate patch. I have prepared one, see attachment.
> 
> 
> 2) IMO this patch does too much, it should only add the Python 3
> equivalent of freeipa-python - python3-ipalib - but none of the other
> packages/provides.

My reasoning for the new packages:
- python3-ipalib is the main point
- freeipa-common contains files that both the py2 and py3 versions need
- python-ipap11helper has compiled code: with this pulled out,
python3-ipalib can be noarch
- python3-ipatests is needed if we want to start testing the py3
packages in  CI

As for new provides, Fedora's Python packaging guidelines say:

"""
Using a fictional module named "example", the subpackage containing
the python2 version must provide python2-example. This is of course
always the case if the subpackage is named python2-example [...]
If the subpackage has some other name then then Provides: python2-example
must be added explicitly (but see the %python_provide macro below).

The python3 subpackage must provide python3-example. However, as the
naming guidelines mandate that the python3 subpackage be named
python3-example, this will happen automatically.
"""

so I'm now adding Provides for the top-level modules.

> 3) Speaking of freeipa-python, it should be renamed to python-ipalib,
> for consistency.
> 
> This should also be a separate patch, again see attachment.

I think that would just be unnecessary churn. Python 3 gives us a chance
for a fresh start, so I'm taking advantage of that, but renaming
existing packages is a pain.

With the right Provides, "dnf install python-ipalib" (or python2-ipalib)
will do the right thing, and I thing that's enough.

> 4) There should be a python3-devel (and also other python3- equivalents
> of python- packages) BuildRequires when Python 3 support is enabled.

I did miss that somehow. Thanks for checking.
I added python3-devel; the others are unnecessary because pylint is not
currently run on the Python3 version.

> 5) This line in ipapython/ipap11helper/Makefile uses a Python 2 print
> statement:
> 
> PYTHONLIBDIR ?= $(shell $(PYTHON) -c "from distutils.sysconfig import *;
> print get_python_lib()")

Thanks, fixed

> 6) The ipalib Makefile is missing the "check" target (see ipapython
> Makefile).

Also fixed.

-- 
Petr Viktorin