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

[Toshio Kuratomi]

On Tue, Apr 27, 2010 at 09:41:02AM +0200, Tarek Ziadé wrote:
> 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.
>
No, I'm not.  The developer needs to establish sane categories, but doesn't
need to worry about the exact paths.  For instance, this would be perfectly
fine:

foo/path.py::
  HELPDIR=os.path.join(os.dirname(__file__), 'help')
  TEMPLATEDIR=pkg_resources.resource_filename('foo', 'templates')
  CACHEDIR=os.path.join(os.environ.get('HOME', '/tmp'), 'foocache')

Then the individual platform packagers can patch the single file, paths.py
according to the neecds oftheir 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.
> 
s/paths/categories/ and I'll agree.   As I said, the PEP does a lot of
things right in this area.  We're able to push decisions about filesystem
paths out to a higher level using the PEP whereas the current state of the
art has us needing to figure it all out as individual developers :-(

[...]
> 
> 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.
> 
I don't think so -- but this scheme certainly allows that.  I think that
many developers who are targeting Linux will find it more natural to specify
FHS compliant paths for their files.  Someone who is developing an app to be
portable will likely find that placing files alongside code is more natural
(although even this isn't truly portable -- CACHEDIR and other stateful
files will break under the assumption that you can write to a file/directory
alongside the module).

And like I say, this is just about the best workaround available now.
Implementation of the PEP makes this area much better.

-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/20100427/7cf05654/attachment-0001.pgp>