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
signature.asc
Description: OpenPGP digital signature
