Currently the primary python-specific way to package compiled Python modules is the "wheel" format [1], which is basically a zip file containing the compiled module with some metadata describing it.
Normally, openSUSE disallows using pre-compiled packages. This typically isn't a problem, since python packages are also usually distributed as sources, either in .tar.gz, .zip, or some other similar format, and contain a script (usually setup.py) to build the module.
However, some very simple packages, specifically those built using the flit tool [2], only provide wheels. They don't provide any script to install the package, they can only be built from source if flit is already present. However, in those cases, the wheel is composed only of uncompiled python script files (.py files) and metadata.
It would conceivably be possible to use flit to build these packages from, for example, github tarballs. However, flit has some serious bootstrapping issues (it depends on packages built using flit), is difficult to install, and it is difficult to get useful files for packaging out of it.
So for packages that don't come with their own build script, and whose wheels lack any compiled code, I think it should be allowed to use the wheel for packaging our rpms.
What does everyone else think?
1: https://www.python.org/dev/peps/pep-0491/ 2: https://pypi.python.org/pypi/flit
So does anyone have any objections or issues with this?
On Tue, Oct 18, 2016 at 8:14 PM, Todd Rme toddrme2178@gmail.com wrote:
Currently the primary python-specific way to package compiled Python modules is the "wheel" format [1], which is basically a zip file containing the compiled module with some metadata describing it.
Normally, openSUSE disallows using pre-compiled packages. This typically isn't a problem, since python packages are also usually distributed as sources, either in .tar.gz, .zip, or some other similar format, and contain a script (usually setup.py) to build the module.
However, some very simple packages, specifically those built using the flit tool [2], only provide wheels. They don't provide any script to install the package, they can only be built from source if flit is already present. However, in those cases, the wheel is composed only of uncompiled python script files (.py files) and metadata.
It would conceivably be possible to use flit to build these packages from, for example, github tarballs. However, flit has some serious bootstrapping issues (it depends on packages built using flit), is difficult to install, and it is difficult to get useful files for packaging out of it.
So for packages that don't come with their own build script, and whose wheels lack any compiled code, I think it should be allowed to use the wheel for packaging our rpms.
What does everyone else think?
1: https://www.python.org/dev/peps/pep-0491/ 2: https://pypi.python.org/pypi/flit
On 19.10.2016 02:14, Todd Rme wrote:
So for packages that don't come with their own build script, and whose wheels lack any compiled code, I think it should be allowed to use the wheel for packaging our rpms.
I'm OK with using wheels in place of source tarball, in these cases as you describe.
Somewhat ambivalent about just dropping the wheel into site-packages and leaving it at that. Fedora allows using wheels, in a way [1], but they unpack them in the %install section (via a patch to pip [2][3] that we don't have but could conceivably adopt). I think we should do the same thing, as opposed to simply installing the wheel, but i don't really have a good reason, just a gut feeling.
m.
[1] https://fedoraproject.org/wiki/PythonWheels [2] https://github.com/pypa/pip/issues/1351 [3] https://github.com/fedora-python/rewheel/blob/92fd4dd0f14fb007323d8032b3dc9e...
On Wed, Oct 26, 2016 at 11:47 AM, jan matejek jmatejek@suse.com wrote:
On 19.10.2016 02:14, Todd Rme wrote:
So for packages that don't come with their own build script, and whose wheels lack any compiled code, I think it should be allowed to use the wheel for packaging our rpms.
I'm OK with using wheels in place of source tarball, in these cases as you describe.
Somewhat ambivalent about just dropping the wheel into site-packages and leaving it at that. Fedora allows using wheels, in a way [1], but they unpack them in the %install section (via a patch to pip [2][3] that we don't have but could conceivably adopt). I think we should do the same thing, as opposed to simply installing the wheel, but i don't really have a good reason, just a gut feeling.
m.
[1] https://fedoraproject.org/wiki/PythonWheels [2] https://github.com/pypa/pip/issues/1351 [3] https://github.com/fedora-python/rewheel/blob/92fd4dd0f14fb007323d8032b3dc9e...
No, I definitely don't want to just drop the wheel in. My thinking was to use pip's --root and --prefix arguments just like setup.py currently supports. For packages that only install python modules and nothing else, this works fine. If it gets to the point where packages that install executables are only available as wheels, I guess we could implement that patch. But right now I am not aware of any packages that require it.
-
jan matejek -
Todd Rme