On 21 December 2013 22:01, Nick Coghlan <[email protected]> wrote: > On 21 December 2013 21:40, Paul Moore <[email protected]> wrote: >> On 21 December 2013 10:57, Nick Coghlan <[email protected]> wrote: >>> It's really the potential for FHS support that drives my interest in >>> the idea, but if we're going to do something like this at all, it >>> shouldn't be POSIX specific. >> >> Agreed in principle. But in practice, do you expect the wheel spec to >> define exactly how each scheme under "app" is mapped? And do you >> expect every tool to implement those features? That implies a lot of >> work getting consensus and a change to the wheel spec every time >> someone thinks of a new platform-specific area that's worth >> supporting. >> >> Maybe this is something that should be handled by the post-install >> hook support. The "app" area could be an area that is reserved in the >> wheel for platform-specific data as you say, but there is no specified >> behaviour for tools to implement. Rather: >> >> 1. Tools must make the "app" area accessible in post-install hooks >> (how is yet to be defined, simplest answer just put it in a temporary >> location on disk, and tell the hooks the location of that location) >> 2. Tools should provide an extensibility mechanism for installing >> system-wide processors for app data (so that we don't need every wheel >> to ship the FHS-handling post-install hooks) >> 3. Standard processing for particular app areas (for example, app/fhs) >> could be defined independently of the wheel spec. >> >> One of the motivations I have here is to keep the install behaviour >> from getting too complex. We need to remember that pip is not the only >> wheel installer (there's distlib and wheel itself). So I don't want to >> mandate too much complexity into the install phase (for example, >> script wrappers aren't handled in wheel install, and I'm not sure what >> distlib does - so there's implementation differences creeping in right >> now). > > Oh, I like that idea. Let me get the next draft of the metadata 2.0 > PEPs cleaned up and published, and then we can discuss it further (I > think it ties into nicely with some of the changes I've made in > response to PJE's feedback on the last draft).
The revised proposal for the hooks mechanism is now up as part of the new standard metadata extensions PEP: http://www.python.org/dev/peps/pep-0459/#the-metadata-hooks-extension This currently just covers step 2 - there's no mechanism for giving such hooks access to files without first putting them in one of the standard locations. It's the first draft of that design though, so I expect it will need a few iterations before we're happy with it. For example, I think a slight tweak to the metadata_hooks extension could extend it to cover this case as well: support a "custom_path" option as a new kind of hook definition. So, for example, you would be able to trap the fhs path this way: "python.metadata_hooks": { "custom_paths": { "fhs": { "postinstall": "fedora_pip.plugins:install_fhs_files", } } } In this case, the signature of the postinstall hook would be slightly different from the one defined in the PEP for extensions and export_groups, since it would also need to include the path to a temporary directory containing the extracted files. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
