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

[Tarek Ziadé]

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 pkg_resources 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.
>

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