[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:49:01 CEST 2010

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 installpath.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.filepaths 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

More information about the Python-Dev mailing list