New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Packaging should provide support for extensible categories #56602
Comments
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 installed for interoperability with them. This can be catered for by a pre-hook for install_data, but some very small core changes are needed:
Just these small changes are sufficient to allow sufficient control over custom installation locations. For projects that need custom categories, they just need to do the necessary setup in an install_data pre-hook: def pre_install_data(cmd):
cmd.categories['customcategory'] = '/path/for/my/custom/category' I have this working in the pythonv branch, and if the feature request is accepted I can work up a patch including changes to docs, tests etc. |
I think this should be part of the setup.cfg specification, not an install_data hook. |
@É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] 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. The two approaches can work together - the categories dictionary can be populated from setup.cfg where this makes sense, and of course for static paths it makes perfect sense. The Windows world is a lot more chaotic than static paths can cater for, unfortunately :-( |
Yep.
Ah, too bad.
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 bpo-7175. |
When you say "let's", do you mean me, or you? :-) Just so we don't *both* do it Re. bpo-7175, the discussion is somewhat orthogonal - the other issue ISTM is |
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 implementation to suit. |
Can you add tests?
If there are many places that could benefit from such a function, we can add it. |
https://bitbucket.org/vinay.sajip/pythonv/changeset/f7c5098e3c3b |
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 looking at Windows binary packaging as discussed recently on python-dev. |
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 method, some parsing and validation is done in the config module (for the metadata, files and soon extension sections), and the section named “global” is validated by the Distribution (or maybe Dispatcher now) class. So I’ll certainly reuse your tests, but will have to redo the implementation. I’m also wondering if install_data’s options are the right place for this. For example, does it make sense to allow “pysetup run install_data --categories spam=blah”? (Any command option can be given on the command line.) Maybe the global section of setup.cfg would be better. |
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 installation time to determine how the categories are set up. My tests don't cater for that, but in my view it's an important requirement that shouldn't be lost. That's why I put the code into a hook, install_data being the one which required minimal changes to the code. I'm not wedded to the specific implementation, simple though it is - I was aiming for a solution that worked and would be easy to review. I agree that install_data may not be the best section for this, and the global section seems more reasonable. But the key thing, apart from the parsing logic etc., is to allow changes / additions to the categories to be made at installation time by user-defined code (=> hook). |
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 though, there will be no validation; this is a general problem with how commands and hooks work. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: