Packaging python wheels

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Packaging python wheels

todd rme
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
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packaging python wheels

todd rme
So does anyone have any objections or issues with this?

On Tue, Oct 18, 2016 at 8:14 PM, Todd Rme <[hidden email]> 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
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packaging python wheels

jan matejek-4
In reply to this post by todd rme
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/92fd4dd0f14fb007323d8032b3dc9e1bd6a662bd/python-pip-spec.patch#L100


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packaging python wheels

todd rme
On Wed, Oct 26, 2016 at 11:47 AM, jan matejek <[hidden email]> 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/92fd4dd0f14fb007323d8032b3dc9e1bd6a662bd/python-pip-spec.patch#L100
>

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.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]