Paul Moore <p.f.mo...@gmail.com> added the comment:
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.
----------
nosy: +pmoore
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11805>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
