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

[Tarek Ziadé]

On Tue, Apr 27, 2010 at 2:43 AM, David Cournapeau <cournape at gmail.com> wrote:
> On Tue, Apr 27, 2010 at 5:10 AM, Piotr Ożarowski <piotr at debian.org> wrote:
>
>> if there's no other way (--install-data is ignored right now, and I know
>> you're doing a great work to change that, thanks BTW), one could always
>> use it in *one* place and later import the result in other parts of
>> the code (instead of using __file__ again)
>
> May I ask why this is not actually the solution to resources location
> ? For example, let's say we have (hypothetic version of distutils
> supporting autoconf paths):
>
> python setup.py install --prefix=/usr --datadir=/var/lib/foo
> --manpath=/somefunkypath
>
> Then the install step would generate a file __install_path.py such as:
>
> PREFIX = "/usr"
> DATADIR = "/var/lib/foo"
> MANPATH = "/somfunkypath"
>
> There remains then the problem of relocatable packages, but solving
> this would be easy through a conditional in this generated file:
>
> if RELOCATABLE:
>    PREFIX = "$prefix"
>    ...
> else:
>
> and define $prefix and co from __file__ if necessary. All this would
> be an implementation detail, so that the package developer effectively
> do
>
> from mypkg.file_paths import PREFIX, DATADIR, etc...
>
> This is both simple and flexible: it is not mandatory, it does not
> make life more complicated for python developers who don't care about
> platform X. FWIW, that's the scheme I intend to support in my own
> packaging solution,

That resembles a lot to what we want to achieve in the next PEP:
at installation time, a file that contains all the prefix will be generated,
combined with a global list of variables found in Python.

Then, instead of importing these values (in our plans, the variables
are statically defined), developers will do:

     pkgutil.open('MANPATH', 'foo'),  where foo.txt is a file under
/somefunkypath in your example

Since you are building your own tool, it would be great to have you
working with us in the upcoming PEP,
since it aims to provide an interoperability ground to install and
consume resource files.

Regards
Tarek

-- 
Tarek Ziadé | http://ziade.org