[aur-general] Python packaging: to build or not to build (Re: Review request for 3 related PKGBUILDs)

[Eli Schwartz]

On 02/14/2017 06:11 PM, Bruno Pagani wrote:
> Le 03/01/2017 à 22:36, Eli Schwartz via aur-general a écrit :
> 
>> On 01/03/2017 04:12 PM, Leonid Bloch wrote:
>>> Thanks! That was very helpful!
>>>
>>> All applied, except... "--skip-build" - indeed it makes sense, but I
>>> have never seen it with other Python packages. So I wonder if indeed it
>>> is a good practice, or is there some reason not to include it?
>> Well, python-setuptools does it, but it doesn't seem to be very popular.
>> Really, for Make-powered builds the dependencies for "install" are going
>> to run anyway (but they were built during build() and usually do
>> nothing, silently).
>> Then again, a lot of python PKGBUILDs don't have a build() function at
>> all, which means the package() function will invoke "build" itself.
>> Apparently, there is an arcane difference between building a python
>> module and compiling an ELF binary, but no one has told me what that
>> difference may be... I don't usually pay attention to what other people
>> do. :)
>>
>> It makes no difference whether you look at the repos or the AUR, both
>> have people who do all three styles.
>>
>> The only practical difference would be if someone, say, ran `makepkg
>> --nobuild && makepkg --repackage` on a VCS package, which they shouldn't.
> 
> I’m sort of reviving this thread, because I’ve stumbled upon discussions
> around this recently, and in fact I see one practical reason of doing
> the build in the package() function rather than in the build() one:
> 
> – split python2-lib/python-lib package without build() function (only
> the relevant parts):
> package_python-lib() {
>     python setup.py install --prefix=/usr --root="$pkgdir" --optimize=1
> }
> package_python2-lib(){
>     python2 setup.py install --prefix=/usr --root="$pkgdir" --optimize=1
> }
> 
> – vs with build() function:
> prepare() {
>     cp -a libname{,-py2}
> }
> build() {
>     cd libname
>     python setup.py build
> 
>     cd libname-py2
>     python2 setup.py build
> }
> package_python-lib() {
>     python setup.py install --prefix=/usr --root="$pkgdir" --optimize=1
> --skip-build
> }
> package_python2-lib(){
>     python2 setup.py install --prefix=/usr --root="$pkgdir" --optimize=1
> --skip-build
> }
> 
> Now, whether this is a good practice or not and what may be the
> implications regarding makepkg, that’s a different thing. But it would
> be good to agree on one way or another, and keep it the same everywhere
> for consistency. If they are good reason to do it the second way, I’d
> like to know them. Else, I have a tendency to find the shortest one to
> be the best. ;)

As I explained before, `python* setup.py install` "depends" on `python*
setup.py build`, in much the same way `make install` generally depends
on some target like `make all`.

So, running `python setup.py install` in package_*() is explicitly
identical in effect to running `python setup.py build && python setup.py
install`, just like `make install` would, for the average Makefile, be
identical to `make all && make install`.

Therefore, the *only* question is whether you wish to run `python
setup.py build` separately, in the build() function. But if you felt the
need to make a python2 copy in prepare() before using build(), then you
should also feel the need to make a python2 copy in prepare() when you
*aren't* using a build() function.

The only difference it could make, and this is a difference that would
apply equally to standard Makefile-powered packages as well, would be if
you wanted to build only part of a split package, and therefore skip
building it as well. And makepkg no longer supports building only part
of a split package, so that concern would only be relevant a long time ago.

...

As for making a python2 copy in the first place, that is not always
necessary... any python package which includes a binary extension will
get built in e.g. "build/lib.linux-i686-2.7/" vs.
"build/lib.linux-i686-3.6/", whereas pure *.py packages will get built
in "build/lib/".

The latter don't actually have any python2/python3-specific differences
anyway, usually. The recommended way to support both is, after all, to
write polyglot code that doesn't care which version of python you use.
Although setuptools *can* run 2to3 if the package requests it.

...

tl;dr
Nothing has changed since the last email, and that prepare function is
just as necessary (or possibly unnecessary) with a separate build() as
it is without a separate build().

-- 
Eli Schwartz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20170214/4fc71526/attachment.asc>