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