10

Currently I'm using the auto-tools to build/install and package a project of mine, but I would really like to move to something that feels more "pythonic".

My project consists of two scripts, one module, two glade GUI descriptions, and two .desktop files. It's currently a pure python project, though that's likely to change soon-ish.

Looking at setuptools I can easily see how to deal with everything except the .desktop files; they have to end up in a specific directory so that Gnome can find them.

Is using distuils/setuptools a good idea to begin with?

Brutus
  • 7,139
  • 7
  • 36
  • 41
Magnus
  • 4,644
  • 1
  • 33
  • 49
  • 1
    I know its been 9 years since, but shouldn't `MANIFEST.in` be enough for [adding any non-code file](https://python-packaging.readthedocs.io/en/latest/non-code-files.html)? – jar Nov 20 '18 at 04:07

4 Answers4

5

I managed to get this to work, but it kinda feels to me more like a workaround.

Don't know what's the preferred way to handle this...

I used the following setup.py file (full version is here):

from setuptools import setup

setup(
  # ...
  data_files=[
    ('share/icons/hicolor/scalable/apps', ['data/mypackage.svg']),
    ('share/applications', ['data/mypackage.desktop'])
  ],
  entry_points={
    'console_scripts': ['startit=mypackage.cli:run']
  }
)

The starter script trough entry_points works. But the data_files where put in an egg file and not in the folders specified, so they can't be accessed by the desktop shell.

To work around this, I used the following setup.cfg file:

[install]
single-version-externally-managed=1
record=install.txt

This works. Both data files are created in the right place and the .desktop file is recognized by Gnome.

Brutus
  • 7,139
  • 7
  • 36
  • 41
  • 1
    This is a good start, but doesn't work with --user, as /usr/bin has to be hard-coded for Exec in the .desktop file. You can leave out the path, but then it has to be in the $PATH of the desktop environment, which ~/.local/bin generally isn't. Also, note that --single-version-externally-managed isn't required with pip since it doesn't use eggs. – jwelsh Jan 26 '15 at 19:45
  • @Brutus I know its been 9 years since, but shouldn't `MANIFEST.in` be enough for [adding any non-code file](https://python-packaging.readthedocs.io/en/latest/non-code-files.html)? – jar Nov 20 '18 at 04:06
1

You can try to use python-distutils-extra. The DistUtilsExtra.auto module automatically supports .desktop files, as well as Glade/GtkBuilder .ui files, Python modules and scripts, misc data files, etc.

It should work both with Distutils and Setuptools.

Danilo Piazzalunga
  • 7,590
  • 5
  • 49
  • 75
1

I've created https://pypi.python.org/pypi/install-freedesktop. It creates .desktop files automatically for the gui_scripts entry points, which can be customized through a setup argument, and supports --user as well as system-wide installation. Compared to DistUtilsExtra, it's more narrow in scope and IMHO more pythonic (explicit is better than implicit).

jwelsh
  • 278
  • 2
  • 10
1

In general, yes - everything is better than autotools when building Python projects.

I have good experiences with setuptools so far. However, installing files into fixed locations is not a strength of setuptools - after all, it's not something to build installaters for Python apps, but distribute Python libraries.

For the installation of files which are not application data files (like images, UI files etc) but provide integration into the operating system, you are better off with using a real packaging format (like RPM or deb).

That said, nothing stops you from having the build process based on setuptools and a small make file for installing everything into its rightful place.

Torsten Marek
  • 83,780
  • 21
  • 91
  • 98
  • 1
    So, are you saying that there is nothing pythonic for building/packaging applications written in python? That's a bit disappointing. – Magnus Feb 01 '09 at 21:45
  • 1
    Packaging applications depends on the operating system, not on the programming language. An application package (with installer etc) on Windows has to fulfill different requirements than a .deb package, or a Mac OS X app. – Torsten Marek Feb 02 '09 at 14:30
  • Packaging for an operating system is greatly simplified by choosing a good build environment. Many build environments also double as simplistic packaging systems, often source only, e.g. auto-tools, distutils, ruby gems, ... maybe "distribution system" is a better term. – Magnus Feb 02 '09 at 23:08
  • 1
    Back to the original question, please! Is there a build environment for applications written in Python that is better (more pythonic) than auto-tools? (Keeping in mind that I have to install files into fixed locations.) – Magnus Feb 02 '09 at 23:11