This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author paul.moore
Recipients alexis, eric.araujo, erik.bray, jkloth, paul.moore, tarek
Date 2011-11-03.23:17:38
SpamBayes Score 0.0
Marked as misclassified No
Message-id <1320362259.89.0.0292222533873.issue11805@psf.upfronthosting.co.za>
In-reply-to
Content
I see what you're saying - and looking through sysconfig.cfg, I can see how things are expected to be laid out (and how I'd configure it if I didn't like it :-))

But as far as I can see, there's no way in packaging to describe a module that works like sysconfig itself! (A module with a resource which is expected to live alongside the .py file). Installing the cfg file to {purelib} would work in practice, but if the distribution containing sysconfig was later changed to include a C extension, then the code would get silently switched to install into platlib, and the .cfg file would no longer be alongside the .py file.

(This is only actually the case when purebase and base differ - which never happens on Windows, and I don't really understand when it would happen on Unix. So I can't really say how likely and/or important this possibility is. But it's certainly there.)

I'd like to see an extra category that was guaranteed to point to where the code files were going to be installed (i.e., the same as whichever one of platlib or purelib the packaging installer chooses). With that, it would be possible (but still clumsy) to implement package data reliably.

OK, having said all that, I do think that saying "package_data was wrong, let’s move away from that" is a bit user-unfriendly. Whether it causes issues for OS distributors, or is "wrong" as a matter of principle, people do use it, a lot. It's the basis of the whole egg concept (a package and its data as a single self-contained object), it's used by distutils itself as you mention, as well as in a number of other places in the stdlib. If you don't support it, I predict that people are simply going to invent more and more elaborate hacks to emulate it.

Actually, given that packaging should allow a hook to find out where a given file is going to be installed (if it isn't, expect a feature request :-)), it should be reasonably easy to write a hook to add a custom category for this purpose. But I'd argue that it's better to put the feature in packaging directly, rather than see the same workaround implemented over and over again.
History
Date User Action Args
2011-11-03 23:17:39paul.mooresetrecipients: + paul.moore, tarek, jkloth, eric.araujo, alexis, erik.bray
2011-11-03 23:17:39paul.mooresetmessageid: <1320362259.89.0.0292222533873.issue11805@psf.upfronthosting.co.za>
2011-11-03 23:17:39paul.moorelinkissue11805 messages
2011-11-03 23:17:38paul.moorecreate