On Mon, Apr 20, 2015 at 4:04 PM, Paul Moore <[email protected]> wrote:
> On 20 April 2015 at 20:44, Daniel Holth <[email protected]> wrote:
>> On Mon, Apr 20, 2015 at 3:31 PM, Paul Moore <[email protected]> wrote:
>>> On 20 April 2015 at 20:27, Vinay Sajip <[email protected]> wrote:
>>>> a default mapping specifying the publisher's preference
>>>
>>> I didn't think the project author got to specify a preference. All
>>> they say is what categories various files go into, and it's the
>>> *installer* that maps them to locations.
>>> Paul
>>
>> If an application relied on relative paths from the root of a
>> category, then it would probably include the same folder structure in
>> its development checkout; setup.py would say "copy ./data into
>> $datadir", modulo ignore patterns; it would be convenient if the
>> mechanism pointing to $datadir pointed to ./data.
>
> Hmm, I'm clearly struggling to understand what you're trying to cover
> with the PEP. I don't think it's particularly productive for me to
> keep asking confused questions. I'll wait for the next draft of the
> PEP to be published, to see if it clarifies things for me, rather than
> continually asking the same sorts of question over and over.
If you are writing an application called "borderify" that puts custom
messages inside ornate PDF borders stored as files in the data
category, then your sdist may have a folder "data/border1.pdf". When
it is installed the same file may go into
"/usr/share/borderify/border1.pdf". It would be nice if the same API
"give me border1.pdf in the data category" would return
"data/border1.pdf" during development, but
"/usr/share/borderify/border1.pdf" when installed on Linux.
If the proposed API winds up needing a json file in the development
packagename*.dist-info directory, then you might want it to say {
"data" : "C:\\Users\\me\\Documents\\borderify-dev\\data\\", ... }
during development.
I hadn't really thought about the categories of paths feature from
setup.py all the way through to the package format. I hope we can get
it done with somewhat fewer than 5 peps. It seems it will need much
more explaining than code.
> But can I ask that PEP 491 be recast as specifically justifying and
> documenting the *changes* to the wheel spec, and how installers will
> need to change to address these. The current form of the PEP, as an
> updated version of the full wheel spec, is far too difficult to
> understand (having to spot the changes by in effect doing a mental
> diff between the two PEPs is a big problem, as is the lack of any
> obvious place to document *why* the changes have been made). This ties
> in with Nick's proposal to hold specs externally, and make PEPs into
> proposals for changes to the specs, rather than specs themselves.
It will be edited. The current draft exists to motivate discussion.
_______________________________________________
Distutils-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/distutils-sig
