pip2pkgbuild icon indicating copy to clipboard operation
pip2pkgbuild copied to clipboard

Add support for wheels!

Open ninjaaron opened this issue 9 years ago • 3 comments

I love using pip2pkgbuild because I don't know much about PKGBUILD scripts myself. The one problem is that it always uses setup.py to build the package. making wheels with pip and installing as wheels from pip offers several advantages, including that the setup.py file never has root, compiled components can be distributed as binaries, modules ship with bytecode compiled and entry_points generates much faster startup scripts.

It would be awesome if pip2pkgbuild supported this installation method!

ninjaaron avatar Aug 04 '16 22:08 ninjaaron

Firstly, sorry for so late to reply and thanks for using pip2pkgbuild.

I have no idea about how wheels work and how to fit it into the packaging process of PKGBUILD. If you have an example PKGBUILD file that use this way of packaging I would like to have a try to add this feature.

Something I want to mention, a Arch Linux package's build process is performed within the packaging time (when you run makepkg from a directory contained a PKGBUILD), after packaging you got a <package-name>.pkg.<archive-format> file (the package), so, a python module Arch Linux package will always ships with bytecode compiled and binary compiled components.

wenLiangcan avatar Nov 27 '16 07:11 wenLiangcan

http://pythonwheels.com/

Packages made from wheels would probably not be allowed in the AUR since they may contain binaries (shared objects). Wheels would probably only be allowed once the package makes the community repository.

The wheel file may be architecture dependent since it may contain compiled c extensions. It also may be minor version dependent. i.e. Python 3.4 only or Python 3.5 only.

You would replace the source of the PKGBUILD with the wheel file instead, so I guess the source may need to change depending on the architecture.

The build() function would no longer be needed. The package() functions would be using pip to install the wheel, so pip would need to be added to makedepends. Note that this doesn't mean pip is fetching the wheel, but just installing the .whl file into the system.

Also note pypi json contains wheels as bdist_wheel.

A good example is numpy: https://pypi.python.org/pypi/numpy

brycepg avatar Dec 02 '16 04:12 brycepg

I'm not sure if this resolves all the issues you bring up, but here's something of mine I've packaged to use wheels: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pyfil

The wheel is created from source at build() time in the PKGBUILD. pip (and wheel!) are indeed makedepends. This is the script I used to generate it (inspired by pip2pkgbuild, though it is much simpler, being only designed to fit my personal usecase): https://github.com/ninjaaron/dot/blob/master/bin/pkg.py

As a side note, I can assure you that building packages in the normal manner with setup.py does not generate bytecode, though naturally, compiled extensions from C or whatever are built. Check the files from the pip2pkgbuild package and verify.

The only possible downside I can see is that the bytecode will no longer be valid when new versions of python are released, but then it can fall back to source (which leaves us in a situation no worse than using setup.py). This can be amended by rebuilding the package with the new version of python. Well, I guess requiring pip and wheel might also be a downside, but I feel like these are pretty basic dependencies for most systems running python.

One final note is that there are many, many packages in the AUR that fetch binaries and do not actually build from source. This is what my script originally did, but I changed it later to build the wheels locally since I believe this to be more in line with the spirit of the AUR (even if it is not always observed in practice.

ninjaaron avatar Dec 02 '16 09:12 ninjaaron