[issue12393] Packaging should provide support for extensible categories

New submission from Vinay Sajip : Some installation locations are platform-dependent and cannot be categorised into a small but fixed number of categories. This is particularly true for the Windows ecosystem - PowerShell, Office, SharePoint all have specific locations where files need to be in

[issue12393] Packaging should provide support for extensible categories

Éric Araujo added the comment: I think this should be part of the setup.cfg specification, not an install_data hook. -- ___ Python tracker ___ _

[issue12393] Packaging should provide support for extensible categories

Vinay Sajip added the comment: @Éric: I agree that some support in setup.cfg would be good, but the problem is that you can't be 100% declarative - sometime the locations can only be determined at runtime. I assume you are thinking of something like: [install_data] categories = cat1 =

[issue12393] Packaging should provide support for extensible categories

Éric Araujo added the comment: > I assume you are thinking of something like: Yep. > In my specific use case, declarative paths will not work in all > scenarios - you have to use ctypes to call a Windows API > (SHGetKnownFolderPath) to find the specific place to put things. Ah, too bad. > The

[issue12393] Packaging should provide support for extensible categories

Vinay Sajip added the comment: > Yes. Let’s implement this in setup.cfg and document how to write a hook to >call Windows APIs to get app-specific paths. See also #7175. When you say "let's", do you mean me, or you? :-) Just so we don't *both* do it ... Re. #7175, the discussion is somew

[issue12393] Packaging should provide support for extensible categories

Vinay Sajip added the comment: Basic support for categories now added to install_data: https://bitbucket.org/vinay.sajip/pythonv/changeset/a4822be62d90 I couldn't see a packaging.util function for matching lines of type "key = value", but if there's one I missed, I can change the implementati

[issue12393] Packaging should provide support for extensible categories

Éric Araujo added the comment: I’ve had a look at your implementation. It is an interesting use of properties, but doesn’t quite fit into how packaging works. Most of the options parsing and validation (from config files and command-line alike) is done in each command’s finalize_options met

[issue12393] Packaging should provide support for extensible categories

Vinay Sajip added the comment: > So I’ll certainly reuse your tests, but will have to redo the implementation. That's fine, but please bear in mind what I said about a 100% declarative approach being insufficient - see the Windows example I gave, where Windows APIs have to be called at instal

[issue12393] Packaging should provide support for extensible categories

Éric Araujo added the comment: > That's fine, but please bear in mind what I said about a 100% declarative > approach being insufficient Well, the config file approach supports simple cases, and for people needing Windows API calls, they will be able to use a pre-command hook. In that case t

[issue12393] Packaging should provide support for extensible categories

Éric Araujo added the comment: > Basic support for categories now added to install_data: Can you add tests? > I couldn't see a packaging.util function for matching lines of type > "key = value", If there are many places that could benefit from such a function, we can add it. -- assigne

[issue12393] Packaging should provide support for extensible categories

Vinay Sajip added the comment: > Can you add tests? https://bitbucket.org/vinay.sajip/pythonv/changeset/f7c5098e3c3b -- ___ Python tracker ___ _

[issue12393] Packaging should provide support for extensible categories

Éric Araujo added the comment: Great. Do you want to update the docs (packaging/setupscript and maybe packaging/commandref too) or shall I do it? -- ___ Python tracker ___ ___

[issue12393] Packaging should provide support for extensible categories

Vinay Sajip added the comment: > Great.  Do you want to update the docs (packaging/setupscript and maybe > packaging/commandref too) or shall I do it? Feel free to do it, if that's OK with you. I've got a couple of other pythonv issues which are taking my time at the moment, plus I am also l