[Python-Dev] what to do if you don't want your module in Debian (original) (raw)

Toshio Kuratomi a.badger at gmail.com
Tue Apr 27 01:24:38 CEST 2010

On Mon, Apr 26, 2010 at 05:46:55PM -0400, Barry Warsaw wrote:

On Apr 26, 2010, at 09:39 PM, Tarek Ziadé wrote:

>You should be permissive on that one. Until we know how to describe resource >files properly, file is what developer use when they need their projects >to be portable.. Until then, isn't pkgresources the best practice for this? (I'm pretty sure we've talked about this before.) I would have to say no to this. Best practice from the Linux packager POV would be something like this

foo/ foo/init.py foo/paths.py::

Global paths where resources are installed

HELPDIR='/usr/share/foo/help' TEMPLATEDIR='/usr/share/foo/templates' CACHEDIR='/var/cache/foo' DBDIR='/var/lib/foo/db' PRIVATEMODDIR='/usr/share/foo/foolib' PLUGINDIR='/usr/lib/foo/plugins' LOCALEDIR='/usr/share/locale'

foo/do_things.py:: import foo.paths import os.path

connect to the db

db = foo_connect(os.path.join(foo.paths.DBDIR, 'foodb.sqlite'))

Using this strategy, you, the developer, can set the default paths to whatever makes the most sense for your target but the packager can go through and patch new locations in a single file that are used throughout your program.

Note that you can use pkg_resources.resource_filename() in the above scenario for static resources (but not stateful ones like database files, caches, and the like). Unfortunately, pkg_resources.resource_stream() can't be adapted to the same purpose.

A better version of resource_stream() based on the work that Tarek's been doing in the backend would be possible for making a resource_stream() capable of handling settable paths as it would pull the pathname determinaiton to the level behind the resource_stream call.

-Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20100426/981cd3c5/attachment.pgp>

More information about the Python-Dev mailing list