You are not logged in.

#1 2017-08-22 09:06:18

juanrubio
Member
Registered: 2017-08-21
Posts: 3

PKGBUILD review request: tizonia

Hello,

I'm trying to get Tizonia in the AUR and I'm creating two packages:

- a "release" package, for the latest tag in the repo (0.9.0)
- a git package

Both PKGBUILD files can be found here:
https://github.com/tizonia/tizonia-open … r/pkgbuild

I've been using Linux for 20 years, but I'm completely new to Arch, so feedback on these two packages would be very much appreciated.

More specifically, I would like to understand how people go about Python 2 vs Python 3 and AUR packages. Here is the problem:
- Tizonia is mostly written in C/C++, but it also embeds Python to interface with Python APIs like gmusicapi, etc.

Currently Tizonia requires Python 2; it's not yet fully compatible with Python 3. So to get things to work, I trick the environment as explained in:
https://wiki.archlinux.org/index.php/python#Python_2

$ ln -s /usr/bin/python2 ~/bin/python
$ ln -s /usr/bin/python2-config ~/bin/python-config

So I'm wondering if AUR packages are ALL expected to be Python 3 compatible, since I can't see a way to make this trick available to end users while installing Tizonia from AUR.

Thanks in advance

Offline

#2 2017-08-22 21:46:51

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: PKGBUILD review request: tizonia

Um, no. The recommended way to do that was *not* to trick the environment, as the Wiki said "you may not be able to control the script calls, but there is a way to trick the environment".

Well, if tizonia is your work, (or at least something you are a collaborator on), then you certainly have the power to fix it. It is inappropriate for python source files to use the python command unless they have documented support for both Python 2 and Python 3 in the same file. Please make tizonia PEP 394 compliant and fix the shebang lines to explicitly use the cross-platform and cross-distro method of specifying the desired version of Python in the project source code.

...

For AUR maintainers who do not have commit access to the upstream project, who have repeatedly tried to convince upstream to fix their code and repeatedly been rebuffed by an upstream which simply does not care about working on anything other than debian (even after becoming aware that some distros, e.g. Arch, *need* PEP 394 compliance), and who want to publish a PKGBUILD for a python2 project... AUR packages are not expected to be Python 3 compatible. The maintainer is responsible for applying a simple sed command to fix the shebang lines of all the files, in the PKGBUILD prepare() function. Essentially, doing in the PKGBUILD what upstream should have done, well, upstream.

Or in some cases, where the build system (mis)uses Python 2, but the installed software does not, the maintainer can do what the Firefox PKGBUILD does:

mkdir -p "$srcdir/path"
ln -s /usr/bin/python2 path/python
export PATH="$srcdir/path:$PATH"

...

Aside: Python comes with perfectly decent pkg-config files, why did you even mention the legacy script which exists only for people who don't have sane things like pkg-config installed? big_smile

Last edited by eschwartz (2017-08-22 21:56:44)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#3 2017-08-22 23:53:35

juanrubio
Member
Registered: 2017-08-21
Posts: 3

Re: PKGBUILD review request: tizonia

Thanks for your reply, really interesting.

Tizonia's Python modules do not include a shebang since they are never executed directly from the shell. They are fed to the interpreter at run-time by virtue of boost.python. I.e. the only "upstream" fix possible here is the conversion of all Tizonia's Python modules to Python 3. Fair enough, but that solution I already knew about :-).

However, the second part of your comment is what I was really looking for. Essentially, what the firefox PKGBUILD does is to trick the environment at package build time.

In summary, in AUR, C/C++ programs that *embed* Python need to be Python 3 compatible or alternatively use the environment trick during the prepare/build stages.

Last edited by juanrubio (2017-08-22 23:55:15)

Offline

#4 2017-08-23 01:13:53

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: PKGBUILD review request: tizonia

I see. embedded python is indeed more complex than that. big_smile

But, boost.python can be built with either Python 2 or Python 3, and in fact the boost-libs package contains both libboost_python3.so and libboost_python.so -- so you should be able to build the C/C++ code against the python2 interpreter. Hopefully that can be done upstream. wink

Where the /usr/bin/python symlink points to isn't... quite as relevant when dealing with embedded python anyway.

Last edited by eschwartz (2017-08-23 01:26:30)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#5 2017-08-23 17:15:07

juanrubio
Member
Registered: 2017-08-21
Posts: 3

Re: PKGBUILD review request: tizonia

Thanks, yes, Boost.Python supports both Python 2 and 3. But this is not the problem it seems.

In Tizonia, autotools is used to configure the project, and in the various places where Python is required, the AM_PATH_PYTHON macro  is used (https://www.gnu.org/software/automake/m … ython.html), like this

AM_PATH_PYTHON([2.7])

It appears that without the environment trick, this in Arch installations ends up finding the Python 3 run-time. I've no idea why, but I'm good with the PKGBUILD trick for now. At some point in the future Python 3 compatibility will be added to Tizonia's Python code and that should make this a moot point (hopefully :-) ).

Offline

#6 2017-08-23 17:53:31

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: PKGBUILD review request: tizonia

"The first argument, if present, is the minimum version of Python required for this package". And it checks for the first available satisfier where PEP 394 is not respected. autotools is stupid sad and you have apparently imported their PEP 394 noncompliance rather than being noncompliant yourself.
See e.g. https://www.mail-archive.com/automake-p … 06942.html

However, what you can do is set PYTHON=python2 and autotools will pick that up. There are a number of packages that do this for ./configure scripts, actually.
This does seem to be a bit of a downstream packaging problem, unless you want to complain to the automake people or migrate to some other build system.

Though it does seem slightly odd that Tizonia compiled perfectly using libpython3 and then fails on the runtime *.py files, but maybe boost is making that easy for you.

Last edited by eschwartz (2017-08-23 17:57:21)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

Board footer

Powered by FluxBB