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

[Bruno Pagani]

Le 15/02/2017 à 01:20, Eli Schwartz a écrit :

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

Yes, but I know no split packages other than python ones for which
running make install alone serves any purpose.

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

OK, I admit having borrowed my example from setuptools since that’s the
only one I know (and that’s only thanks to you), I had no idea the copy
wasn’t necessary generally.

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

So, if I understand things well, python{,2} setup.py build should do the
same thing for most package, and any one of the two could be used to
then package the two versions? So this would work:
build() {
    python setup.py build
}
package_python-lib() {
    python setup.py install --root="$pkgdir" --optimize=1 --skip-build
}
package_python2-lib(){
    python2 setup.py install --root="$pkgdir" --optimize=1 --skip-build
}

Then I would be more in favour of splitting build and package.

Thanks for your input,
Bruno

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