Re: [Python-Dev] what to do if you don't want your module in Debian
On Tue, Apr 27, 2010 at 1:24 AM, Toshio Kuratomi a.bad...@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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Tue, Apr 27, 2010 at 2:43 AM, David Cournapeau courn...@gmail.com wrote:
On Tue, Apr 27, 2010 at 5:10 AM, Piotr Ożarowski pi...@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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
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.bad...@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
pgpKhyjpUdu25.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] what to do if you don't want your module in Debian
Hi, Many Python module developers do not want their work to be distributed by Debian (and probably by other Linux distributions), here's a list of hints that will help you accomplish that goal: * depend on unstable or unreleased software (even if you use it only to generate docs or do unit tests), * bundle local copies of 3rd party modules and do not send your changes upstream, never document your changes in upstream code, * break API in every release, * break ABI in every second release, * do not ship all files needed to build the extension/docs/etc. in the source tarball, * do not list required dependencies in install_requires or INSTALL/README files, * if you list them, make sure you set the minimum required version to the one released yesterday, even if module works fine with version released 2 years ago, * create your own versioning schema (do not follow PEP-0386!), change it from time to time, * hardcode paths in the code and do it in as many places as you can (add new ones every few releases, that will teach them to not patch your code), * ignore FHS (you're using Windows after all); use __file__ whenever you can, * make sure there's nothing about license in LICENSE file or in file headers, * if you have some free time, create your own license, avoid BSD/MIT/(L)GPL, * if you use GPL, do not include full content of the license in the tarball, * release different tarballs with the same version number, * use waf as build-system, * release a new version without testing it with your own unit tests first to ensure that it will fail when your favourite Debian Developer tries to build it ;-) [debian-pyt...@l.d.o BCCed] -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Mon, Apr 26, 2010 at 9:19 PM, Piotr Ożarowski pi...@debian.org wrote: Hi, Many Python module developers do not want their work to be distributed by Debian (and probably by other Linux distributions), here's a list of hints that will help you accomplish that goal: Great hints, I'll try to follow them... and they could make a good section in the Hitchhiker's guide to packaging ;) [...] * ignore FHS (you're using Windows after all); use __file__ whenever you can, 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.. Notice that we have started to work on fixing this - http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
[Tarek Ziadé, 2010-04-26] Great hints, I'll try to follow them... and they could make a good section in the Hitchhiker's guide to packaging ;) How about these two: http://us.pycon.org/media/2010/talkdata/PyCon2010/038/paper.html http://wiki.debian.org/GettingPackaged [...] * ignore FHS (you're using Windows after all); use __file__ whenever you can, 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.. Notice that we have started to work on fixing this - http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst 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) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Mon, Apr 26, 2010 at 10:10 PM, Piotr Ożarowski pi...@debian.org wrote: [Tarek Ziadé, 2010-04-26] Great hints, I'll try to follow them... and they could make a good section in the Hitchhiker's guide to packaging ;) How about these two: http://us.pycon.org/media/2010/talkdata/PyCon2010/038/paper.html http://wiki.debian.org/GettingPackaged Will check these, thx [...] * ignore FHS (you're using Windows after all); use __file__ whenever you can, 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.. Notice that we have started to work on fixing this - http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst 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) Sounds like a good advice to help packagers changing it, we'll add something about that in the guide. Also if you have some time to read it, your feedback as a packager would be appreciated http://guide.python-distribute.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Apr 26, 2010, at 09:19 PM, Piotr Ożarowski wrote: Many Python module developers do not want their work to be distributed by Debian (and probably by other Linux distributions), here's a list of hints that will help you accomplish that goal: Okay, it took me a few bullet items to realize you were being sarcastic. :) I almost starting writing an email asking why anyone would seriously want that. This is a great list. Something I have been thinking about lately dovetails with this, but from a different direction. Let's ask why the problems you enumerate occur, and what can we do about them? For example, there's a nice tool called 'Quickly' that builds application templates using best practices. It is opinionated, but designed for the opportunistic programmer. I've been thinking about writing a Python application and/or library template for this which would make it easy to start a new project automating as much as possible, and doing things The Right Way. It may also be worthwhile putting very obvious carrots (rather than sticks) out there to encourage people to write packages using best practices. For example, once snakebite is operational, I could imagine some kind of automated testing suite for PyPI packages. IOW, if you play by rules A, B and C, we'll automatically grab your new package, build it, run the test suite, and put a gold star on your PyPI page. Some things of course, we can't automate, but I think the HGtP should provide clear examples of best practices, and tools to adhere to them where possible. It is okay (in fact encouraged) to be opinionated and not provide a lot of variation. Advanced developers can figure out how to do complex things correctly, but let's make it easy for the simpler 80% of packages out there. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
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.) -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On 4/26/10 4:46 PM, 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 don't think the OP is really speaking against using __file__ per se, but rather putting data into the package however it is accessed. The Linux-packager preferred practice is to install into the appropriate /usr/shared/ subdirectory. Writing portable libraries (with portable setup.py files!) is difficult to do that way, though. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Mon, Apr 26, 2010 at 11:45 PM, Barry Warsaw ba...@python.org wrote: [..] For example, there's a nice tool called 'Quickly' that builds application templates using best practices. It is opinionated, but designed for the opportunistic programmer. I've been thinking about writing a Python application and/or library template for this which would make it easy to start a new project automating as much as possible, and doing things The Right Way. Related things : - Sean started mkpkg in distutils2, which asks you questions and creates a setup.py file. - Srid created a Paste-based script that creates a project skeleton Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Mon, Apr 26, 2010 at 11:46 PM, Barry Warsaw ba...@python.org 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.) For setuptools-based project I guess it is yes, so you can read them in zipped eggs. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Apr 27, 2010, at 12:03 AM, Tarek Ziadé wrote: On Mon, Apr 26, 2010 at 11:45 PM, Barry Warsaw ba...@python.org wrote: [..] For example, there's a nice tool called 'Quickly' that builds application templates using best practices. It is opinionated, but designed for the opportunistic programmer. I've been thinking about writing a Python application and/or library template for this which would make it easy to start a new project automating as much as possible, and doing things The Right Way. Related things : - Sean started mkpkg in distutils2, which asks you questions and creates a setup.py file. - Srid created a Paste-based script that creates a project skeleton I knew about Srid's but not Sean's. Thanks, I'll take a look. I don't want to stifle innovation here, but let's see if there are commonalities we can share. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Apr 26, 2010, at 04:56 PM, Robert Kern wrote: On 4/26/10 4:46 PM, 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 don't think the OP is really speaking against using __file__ per se, but rather putting data into the package however it is accessed. The Linux-packager preferred practice is to install into the appropriate /usr/shared/ subdirectory. Writing portable libraries (with portable setup.py files!) is difficult to do that way, though. Tarek pointed to the rest page that captured some of the thinking on this developed at Pycon. There's really two sides to it - what does the programmer write and how does that integrate with the system? I really don't think the developer should go through any contortions to make it work right for the platform. For one thing, there's no way they can do it for every platform their code might end up on. It's a lose to attempt it. Tarek's design allows for separation of concerns and indirection so the programmer can worry about the parts they care about, and the platform packagers can worry about the parts they care about. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Mon, Apr 26, 2010 at 11:56 PM, Robert Kern robert.k...@gmail.com wrote:
[..]
I don't think the OP is really speaking against using __file__ per se, but
rather putting data into the package however it is accessed. The
Linux-packager preferred practice is to install into the appropriate
/usr/shared/ subdirectory. Writing portable libraries (with portable
setup.py files!) is difficult to do that way, though.
Well, the only portable way to read a resource file these days in
Python is to put it in your
project source tree so you know for sure you can access it the same way
no matter what the platform is. Thus, using __file__.
The key to fix this is to have a registered list of paths for each
platform at Python level.
Roughly summarized : the work we are doing will consist of defining
variables that points to target paths for each platform (like
/usr/shared in linux) at Python level, and let the developers define
that a file is under a path
defined by a variable (like shared).
For example, a project will be able to read/write the foo.txt file
using: pkgutil.open('shared', 'foo.txt')
pkgutil will look in Python for the path corresponding to shared and
expand it. The result will vary depending
on the platform, and the os packagers will be able to change that path
globally in Python or locally in the project.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Tue, Apr 27, 2010 at 9:15 AM, David Malcolm dmalc...@redhat.com wrote: On Mon, 2010-04-26 at 21:19 +0200, Piotr Ożarowski wrote: Many Python module developers do not want their work to be distributed by Debian (and probably by other Linux distributions), here's a list of Thanks! Not just Debian: I can confirm, from bitter experience, that your list is also highly applicable to Fedora and RHEL... Honestly, it's enough to publish your python application/library/module to pypi (at least this is true for my work). Re-packing some xyz Linux distribution's package mangement system just seems useless and a waste of time (with exceptions ofc). --James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On 27/04/2010 00:26, James Mills wrote: On Tue, Apr 27, 2010 at 9:15 AM, David Malcolmdmalc...@redhat.com wrote: On Mon, 2010-04-26 at 21:19 +0200, Piotr Ożarowski wrote: Many Python module developers do not want their work to be distributed by Debian (and probably by other Linux distributions), here's a list of Thanks! Not just Debian: I can confirm, from bitter experience, that your list is also highly applicable to Fedora and RHEL... Honestly, it's enough to publish your python application/library/module to pypi (at least this is true for my work). Re-packing some xyz Linux distribution's package mangement system just seems useless and a waste of time (with exceptions ofc). The point of the discussion has been how you can structure your package so that Linux distribution maintainers can repackage it *for you* whilst still remaining portable to other platforms. Even if you never intend to repackage your project yourself following these best practises seems like a good idea. (Unless you *really* don't want them packaged for debian - in which case you now have a handy guide telling you how you can ensure this.) All the best, Michael --James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Tue, Apr 27, 2010 at 5:10 AM, Piotr Ożarowski pi...@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, cheers, David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
