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

Tarek Ziadé ziade.tarek at gmail.com
Tue Apr 27 09:41:02 CEST 2010

On Tue, Apr 27, 2010 at 1:24 AM, Toshio Kuratomi <a.badger at gmail.com> wrote:

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/dothings.py::  import foo.paths  import os.path  # connect to the db  db = fooconnect(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.

You are making the assumption that the developers know what are the global paths on each platform. I don't think people would do that unless we provide these paths already, and that's basically the goal of the next PEP.

Maybe a step toward this goal would be to provide a document that explains the role of each path, for each platform from the python developer POV

Until then, the only approach a developer has to make sure he can access to his resource files, is to have them alongside the code.

Regards Tarek

Tarek Ziadé | http://ziade.org

More information about the Python-Dev mailing list