(Created page with "= Python Packaging Notes = {{admon/note||Note that this wikipage contains just my personal notes.}}") |
mNo edit summary |
||
(2 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{admon/warning||This wikipage contains just my personal notes.}} | |||
The use case I have in mind: as an author of a Python module or an application, | |||
I would like to create and maintain Python packages, both in a native | |||
way (installable via pip) and linux distro specific one (eg. rpm for fedora). | |||
Workflow which makes most sense (imho) follows. The main ideas are: | |||
* follow upstream recommendations (upstream first approach, yay!) | |||
* use distro specific tools to automate maintenance of it's packages | |||
== Python packaging == | |||
One should start with | |||
[https://packaging.python.org/en/latest/ Python Packaging User Guide (PyPUG)] | |||
which is maintained by ''Python Packaging Authority'' group. It's really a very | |||
useful overview and you should definitely read it (or at least skim through | |||
it), it will save you a lot of time later in the process. See also the | |||
[https://github.com/pypa/sampleproject PyPA example project] which follows | |||
these guidelines. Especially when starting a new python project, there is a no | |||
good reason to ignore this guide. | |||
On top of that, there is a nice talk discussing how to use setuptools in the | |||
most easier way and what features are better to be avoided: | |||
[https://ep2015.europython.eu/conference/talks/less-known-packaging-features-and-tricks less known packaging features and tricks]. | |||
== Linux distro packaging == | |||
Let's start with the distribution guides: | |||
* [https://fedoraproject.org/wiki/Packaging:Python Packaging Python in Fedora] | |||
* [https://en.opensuse.org/openSUSE:Packaging_Python openSUSE:Packaging Python] | |||
* [https://wiki.debian.org/Python/Packaging Debian Python packaging] | |||
In short: don't create packages manually and don't use tools like | |||
<code>bdist_rpm</code>, but start with distro specific automatic tools which | |||
creates initial specfile of your project for you instead. In that way, you will | |||
have a specfile which follows the guidelines almost for free. | |||
That said, you should still have at least a basic idea what distribution | |||
guidelines states, so that you can check the initial autogenerated file and | |||
tweak details it when necessary. You can't expect that the tool will get | |||
every detail right in all cases. | |||
List of python packaging helper tools: | |||
* [https://github.com/fedora-python/pyp2rpm pyp2rpm] for Fedora | |||
* [https://github.com/saschpe/py2pack py2pack] for OpenSuse | |||
* [https://pypi.python.org/pypi/stdeb py2dsc] for Debian |
Latest revision as of 20:58, 21 February 2016
The use case I have in mind: as an author of a Python module or an application, I would like to create and maintain Python packages, both in a native way (installable via pip) and linux distro specific one (eg. rpm for fedora).
Workflow which makes most sense (imho) follows. The main ideas are:
- follow upstream recommendations (upstream first approach, yay!)
- use distro specific tools to automate maintenance of it's packages
Python packaging
One should start with Python Packaging User Guide (PyPUG) which is maintained by Python Packaging Authority group. It's really a very useful overview and you should definitely read it (or at least skim through it), it will save you a lot of time later in the process. See also the PyPA example project which follows these guidelines. Especially when starting a new python project, there is a no good reason to ignore this guide.
On top of that, there is a nice talk discussing how to use setuptools in the most easier way and what features are better to be avoided: less known packaging features and tricks.
Linux distro packaging
Let's start with the distribution guides:
In short: don't create packages manually and don't use tools like
bdist_rpm
, but start with distro specific automatic tools which
creates initial specfile of your project for you instead. In that way, you will
have a specfile which follows the guidelines almost for free.
That said, you should still have at least a basic idea what distribution
guidelines states, so that you can check the initial autogenerated file and
tweak details it when necessary. You can't expect that the tool will get
every detail right in all cases.
List of python packaging helper tools: