(Created page with "= Python Packaging Notes = {{admon/note||Note that this wikipage contains just my personal notes.}}") |
No edit summary |
||
Line 2: | Line 2: | ||
{{admon/note||Note that this wikipage contains just my personal notes.}} | {{admon/note||Note that this wikipage contains just my personal notes.}} | ||
So there is a 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 python 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 distro package | |||
== 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 all, 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. When starting a new python project, you should follow this guide without any exception. | |||
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 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 should follow the guidelines of the distro without spending hours to study all the details. That said, you should still have a basic idea what distribution guidelines states, so that you can check the initial autogenerated file and tweak details it when necessary. | |||
So you should use: | |||
* [https://github.com/fedora-python/pyp2rpm pyp2rpm] for Fedora | |||
* [https://github.com/saschpe/py2pack py2pack] for OpenSuse | |||
* [https://github.com/paylogic/py2deb py2deb] for Debian |
Revision as of 13:57, 7 February 2016
Python Packaging Notes
So there is a 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 python 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 distro package
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 all, it will save you a lot of time later in the process. See also the PyPA example project which follows these guidelines. When starting a new python project, you should follow this guide without any exception.
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 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 should follow the guidelines of the distro without spending hours to study all the details. That said, you should still have a basic idea what distribution guidelines states, so that you can check the initial autogenerated file and tweak details it when necessary.
So you should use: