2009-02-01 8 views
9

Actualmente estoy usando las herramientas automáticas para construir/instalar y empaquetar un proyecto mío, pero realmente me gustaría moverme a algo que se sienta más "pitónico".Cómo distribuir archivos e iconos `.desktop` para un paquete de Python en Gnome (con distutils o setuptools)?

Mi proyecto consiste en dos scripts, un módulo, dos descripciones de GUI de glade y dos archivos .desktop. Actualmente es un proyecto python puro, aunque es probable que cambie pronto.

En cuanto a las herramientas de configuración, puedo ver fácilmente cómo manejar todo excepto los archivos .desktop; tienen que terminar en un directorio específico para que Gnome pueda encontrarlos.

¿Está utilizando distuils/setuptools una buena idea para empezar?

Respuesta

4

Me las arreglé para hacer que esto funcione, pero me parece un poco más como una solución .

No sabe cuál es la mejor forma de manejar esto ...

he utilizado la setup.py siguiente archivo (versión completa es 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'] 
    } 
) 

El canal script de arranque entry_points obras. Pero el data_files donde se coloca en un archivo huevo y no en las carpetas especificadas, por lo que no se puede acceder por el shell del escritorio.

Para evitar esto, he utilizado la setup.cfg siguiente archivo:

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

Esto funciona. Ambos archivos de datos se crean en el lugar correcto y el archivo .desktop es reconocido por Gnome.

+1

Este es un buen comienzo, pero no funciona con --user, ya que/usr/bin tiene que estar codificado para Exec en el archivo .desktop . Puede omitir el camino, pero luego tiene que estar en $ PATH del entorno de escritorio, lo que generalmente no es ~/.local/bin. Además, tenga en cuenta que --single-version-externally-managed no se requiere con pip ya que no usa eggs. – jwelsh

1

En general, sí, todo es mejor que autotools al construir proyectos de Python.

Tengo buenas experiencias con setuptools hasta ahora. Sin embargo, instalar archivos en ubicaciones fijas no es una fortaleza de las herramientas de configuración; después de todo, no es algo para construir instaladores para aplicaciones de Python, sino distribuir bibliotecas de Python.

Para la instalación de archivos que no son archivos de datos de aplicaciones (como imágenes, UI, etc.) pero proporcionan integración en el sistema operativo, es mejor usar un formato de empaquetado real (como RPM o deb).

Dicho esto, nada le impide tener el proceso de compilación basado en setuptools y un pequeño archivo make para instalar todo en el lugar que le corresponde.

+0

Entonces, ¿estás diciendo que no hay nada pitónico para construir/empaquetar aplicaciones escritas en python? Eso es un poco decepcionante. – Magnus

+1

Las aplicaciones de empaquetado dependen del sistema operativo, no del lenguaje de programación. Un paquete de aplicación (con instalador, etc.) en Windows debe cumplir requisitos diferentes que un paquete .deb o una aplicación Mac OS X. –

+0

El empaquetado de un sistema operativo se simplifica enormemente al elegir un buen entorno de construcción. Muchos entornos de construcción también funcionan como sistemas de empaquetamiento simplistas, a menudo solo como fuente, p. auto-herramientas, distutils, ruby ​​gems, ... tal vez "sistema de distribución" es un término mejor. – Magnus

1

Puede intentar usar python-distutils-extra. El módulo DistUtilsExtra.auto automáticamente supports archivos .desktop, así como los archivos Glade/GtkBuilder .ui, módulos y scripts de Python, archivos de datos misceláneos, etc.

Se debe trabajar tanto con Distutils y Setuptools.

1

He creado https://pypi.python.org/pypi/install-freedesktop. Crea archivos .desktop automáticamente para los puntos de entrada gui_scripts, que se pueden personalizar a través de un argumento de configuración, y es compatible con --user, así como con la instalación de todo el sistema.Comparado con DistUtilsExtra, es más estrecho en alcance y en mi humilde opinión más pythonic (explícito es mejor que implícito).

Cuestiones relacionadas