On 01/03/2017 03:51 AM, Eli Schwartz wrote:

and save on checking for updated source files in build().

Obviously, I meant to say "updated source files already checked in build". :D Specifically, not rerunning setuptools "build" ==> "build_py" in package() and skipping straight to "install" ==> "install_lib". -- Eli Schwartz

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

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. ;) Regards, Bruno

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

On 02/15/2017 02:43 AM, Eli Schwartz via aur-general wrote:

On 02/14/2017 07:44 PM, Bruno Pagani wrote:

...

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

Basically, yeah. Run the setuptools PKGBUILD and diff the srcdir -- you'll see they are practically byte-identical. There is a small handful of 2/3 references, but setuptools rewrote those in the first place, and other than that there's just __pycache__ vs side-by-side bytecode.

https://paste.xinu.at/aY2BmFZryz/

It of cause always depends on the package and how and what it does. Consider you want to run some test suite with py.test or an own suite not strictly wired to setuptools, then you need to build before the package. On top of this it may also contain native code and compile a .so library (that will also be needed in the test suite), in such case you will also need to build for both, python2 and python3 before being able to run the test suits. Just wanted to leave this as a small hint :] cheers, Levente