On 7 December 2013 08:19, Nick Coghlan <ncogh...@gmail.com> wrote:
> That means that you can ship relatively arbitrary software in a wheel
> file by dumping it in "{distribution}-{version}.data/data/<path>", and
> then installing it to the appropriate target location (e.g. if you use
> FHS paths inside the data directory, then you would just need to
> install the wheel as "pip install --root /" to get things into the
> desired location).
>
> However, you'd be forgiven for not realising that from the sysconfig
> docs - I certainly didn't realise it until Daniel pointed it out. From
> the sysconfig docs, I had expected "data" to mean "application data
> files" not "arbitrary, potentially executable, file with no assigned
> semantics".The problem with what you're proposing (which isn't a change, as you say, so much as a subtle reinterpretation) is that if you include something in a wheel under <data>/etc or <data>/usr/include, you *are* assigning semantics to it - and the semantics you are assigning is POSIX. That's not a disaster, of course, but can make for a less than ideal layout on Windows. For example, if packages started putting config data under "etc" that would not be normal Windows practice. It's not *bad* per se, just disconcerting (and TBH, when I've seen this done, it gives the impression of a lazily-ported Unix package). Also, this paves the way for people starting to put data files under "<data>/usr/share" or whatever the FHS location is. That is definitely *not* the Python convention, which is to put the data inside the package and locate it via package_data(). It also makes the package fail when used zipped or via tools like py2exe. So while I have no issue with this practice as a means of dealing with things like the RPM build issue for purely POSIX packages, I do think we should be careful about raising its visibility too much. Personally, I see it as a last resort "escape hatch" for data that simply cannot be placed in any of the standard Python locations. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
