Quantcast

Review request for 3 related PKGBUILDs

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Review request for 3 related PKGBUILDs

Leonid Bloch-2
Hi,

I'd like to put 3 new packages in the AUR. They are a part of one
"kit", but are very different in functionality, therefore I think it
will be better to introduce 3 packages, instead of one, which contains
them all. You can see the details on: http://www.silx.org .
Essentially, these are 3 completely different packages, that just
happen to be used by the same community.

These PKGBUILDs were tested successfully on a minimally-installed VM.

Any feedback is welcome! :)

Thanks!
Leonid.

For silx:
~~~~~~~~~
# Package maintainer: Leonid B <leonid dot bloch at esrf dot fr>
# Upstream contact: silx at esrf dot fr
pkgname=python-silx
pkgver=0.3.0
pkgrel=1
pkgdesc="A collection of Python packages for data analysis at
synchrotron radiation facilities."
arch=('any')
url="http://www.silx.org"
license=('MIT' 'LGPL')
depends=('python-numpy' 'python-pyqt5' 'python-matplotlib' 'cython')
optdepends=('python-h5py: for HDF5 input/output'
            'ipython: for interactive console'
            'python-qtconsole: for GUI console'
            'python-pyopencl: for sift - OpenCL implementation')
makedepends=('git')
source=("${pkgname}::git+https://github.com/silx-kit/${pkgname#*-}.git#tag=v${pkgver}")
md5sums=('SKIP')

build() {
    cd "${srcdir}/${pkgname}"
    python setup.py build
}

package() {
    cd "${srcdir}/${pkgname}"
    python setup.py install --root="${pkgdir}/"
    install -D copyright "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
}


For FabIO:
~~~~~~~~~
# Package maintainer: Leonid B <leonid dot bloch at esrf dot fr>
# Upstream contact: silx at esrf dot fr
pkgname=python-fabio
pkgver=0.4.0
pkgrel=1
pkgdesc="I/O library for images produced by 2D X-ray detectors."
arch=('any')
url="http://www.silx.org"
license=('MIT' 'LGPL' 'Apache')
depends=('python-numpy' 'python-pillow' 'python-lxml')
optdepends=('python-pyqt4: for the fabio_viewer program')
makedepends=('git')
source=("${pkgname}::git+https://github.com/silx-kit/${pkgname#*-}.git#tag=v${pkgver}")
md5sums=('SKIP')

build() {
    cd "${srcdir}/${pkgname}"
    python setup.py build
}

package() {
    cd "${srcdir}/${pkgname}"
    python setup.py install --root="${pkgdir}/"
    install -D copyright "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
}


For pyFAI:
~~~~~~~~~
# Package maintainer: Leonid B <leonid dot bloch at esrf dot fr>
# Upstream contact: silx at esrf dot fr
pkgname=python-pyfai
pkgver=0.13.0
pkgrel=1
pkgdesc="Fast Azimuthal Integration in Python."
arch=('any')
url="http://www.silx.org"
license=('GPLv3' 'BSD' 'MIT')
depends=('python-numpy' 'python-scipy' 'python-matplotlib' 'python-fabio'
         'python-h5py' 'python-pyopencl' 'python-pyqt4' 'fftw' 'cython')
makedepends=('git')
source=("${pkgname}::git+https://github.com/silx-kit/pyFAI.git#tag=v${pkgver}")
md5sums=('SKIP')

build() {
    cd "${srcdir}/${pkgname}"
    python setup.py build
}

package() {
    cd "${srcdir}/${pkgname}"
    python setup.py install --root="${pkgdir}/"
    install -D LICENSES.txt "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
    install -D copyright "${pkgdir}/usr/share/licenses/${pkgname}/COPYRIGHT"
}
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Review request for 3 related PKGBUILDs

Marcin Wieczorek

You should never use git for downloading tagged releases. Copy the url of the tar.gz from github and replace the version with pkgver. That way you can use the sums (sha preferably).
Marcin Wieczorek  wtorek, 03 stycznia 2017, 09:14AM +01:00 od Leonid Bloch  [hidden email] :

>Hi,
>
>I'd like to put 3 new packages in the AUR. They are a part of one
>"kit", but are very different in functionality, therefore I think it
>will be better to introduce 3 packages, instead of one, which contains
>them all. You can see the details on:  http://www.silx.org .
>Essentially, these are 3 completely different packages, that just
>happen to be used by the same community.
>
>These PKGBUILDs were tested successfully on a minimally-installed VM.
>
>Any feedback is welcome! :)
>
>Thanks!
>Leonid.
>
>For silx:
>~~~~~~~~~
># Package maintainer: Leonid B <leonid dot bloch at esrf dot fr>
># Upstream contact: silx at esrf dot fr
>pkgname=python-silx
>pkgver=0.3.0
>pkgrel=1
>pkgdesc="A collection of Python packages for data analysis at
>synchrotron radiation facilities."
>arch=('any')
>url="http://www.silx.org"
>license=('MIT' 'LGPL')
>depends=('python-numpy' 'python-pyqt5' 'python-matplotlib' 'cython')
>optdepends=('python-h5py: for HDF5 input/output'
>            'ipython: for interactive console'
>            'python-qtconsole: for GUI console'
>            'python-pyopencl: for sift - OpenCL implementation')
>makedepends=('git')
>source=("${pkgname}::git+https://github.com/silx-kit/${pkgname#*-}.git#tag=v${pkgver}")
>md5sums=('SKIP')
>
>build() {
>    cd "${srcdir}/${pkgname}"
>    python setup.py build
>}
>
>package() {
>    cd "${srcdir}/${pkgname}"
>    python setup.py install --root="${pkgdir}/"
>    install -D copyright "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
>}
>
>
>For FabIO:
>~~~~~~~~~
># Package maintainer: Leonid B <leonid dot bloch at esrf dot fr>
># Upstream contact: silx at esrf dot fr
>pkgname=python-fabio
>pkgver=0.4.0
>pkgrel=1
>pkgdesc="I/O library for images produced by 2D X-ray detectors."
>arch=('any')
>url="http://www.silx.org"
>license=('MIT' 'LGPL' 'Apache')
>depends=('python-numpy' 'python-pillow' 'python-lxml')
>optdepends=('python-pyqt4: for the fabio_viewer program')
>makedepends=('git')
>source=("${pkgname}::git+https://github.com/silx-kit/${pkgname#*-}.git#tag=v${pkgver}")
>md5sums=('SKIP')
>
>build() {
>    cd "${srcdir}/${pkgname}"
>    python setup.py build
>}
>
>package() {
>    cd "${srcdir}/${pkgname}"
>    python setup.py install --root="${pkgdir}/"
>    install -D copyright "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
>}
>
>
>For pyFAI:
>~~~~~~~~~
># Package maintainer: Leonid B <leonid dot bloch at esrf dot fr>
># Upstream contact: silx at esrf dot fr
>pkgname=python-pyfai
>pkgver=0.13.0
>pkgrel=1
>pkgdesc="Fast Azimuthal Integration in Python."
>arch=('any')
>url="http://www.silx.org"
>license=('GPLv3' 'BSD' 'MIT')
>depends=('python-numpy' 'python-scipy' 'python-matplotlib' 'python-fabio'
>         'python-h5py' 'python-pyopencl' 'python-pyqt4' 'fftw' 'cython')
>makedepends=('git')
>source=("${pkgname}::git+https://github.com/silx-kit/pyFAI.git#tag=v${pkgver}")
>md5sums=('SKIP')
>
>build() {
>    cd "${srcdir}/${pkgname}"
>    python setup.py build
>}
>
>package() {
>    cd "${srcdir}/${pkgname}"
>    python setup.py install --root="${pkgdir}/"
>    install -D LICENSES.txt "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
>    install -D copyright "${pkgdir}/usr/share/licenses/${pkgname}/COPYRIGHT"
>}
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Review request for 3 related PKGBUILDs

tur-users mailing list
In reply to this post by Leonid Bloch-2
On 01/03/2017 03:14 AM, Leonid Bloch wrote:

> I'd like to put 3 new packages in the AUR. They are a part of one
> "kit", but are very different in functionality, therefore I think it
> will be better to introduce 3 packages, instead of one, which contains
> them all. You can see the details on: http://www.silx.org .
> Essentially, these are 3 completely different packages, that just
> happen to be used by the same community.
>
> These PKGBUILDs were tested successfully on a minimally-installed VM.
>
> Any feedback is welcome! :)
Looks mostly okay to me. Usually python packages are installed with
"--optimize=1", and you *might* want to add "--skip-build" to package()
and save on checking for updated source files in build().
Also, why are you cloning the entire repo as opposed to merely grabbing
the archive from "${repo_url}/archive/$v${pkgver}.tar.gz"?

--
Eli Schwartz


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Review request for 3 related PKGBUILDs

tur-users mailing list
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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Review request for 3 related PKGBUILDs

Leonid Bloch-2
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?

Leonid.

On Tue, Jan 3, 2017 at 10:56 AM, Eli Schwartz via aur-general <
[hidden email]> wrote:

> 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
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Review request for 3 related PKGBUILDs

tur-users mailing list
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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Review request for 3 related PKGBUILDs

Leonid Bloch-2
Thanks for the explanation, Eli!

On Tue, Jan 3, 2017 at 11:36 PM, Eli Schwartz <[hidden email]> wrote:

> 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
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Python packaging: to build or not to build (Re: Review request for 3 related PKGBUILDs)

tur-users mailing list
In reply to this post by tur-users mailing list
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


signature.asc (531 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Python packaging: to build or not to build (Re: Review request for 3 related PKGBUILDs)

tur-users mailing list
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Python packaging: to build or not to build (Re: Review request for 3 related PKGBUILDs)

tur-users mailing list
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


signature.asc (531 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Python packaging: to build or not to build (Re: Review request for 3 related PKGBUILDs)

tur-users mailing list
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/

--
Eli Schwartz


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Python packaging: to build or not to build (Re: Review request for 3 related PKGBUILDs)

Levente Polyak-3
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


signature.asc (849 bytes) Download Attachment
Loading...