Repository navigation
Packaging should provide support for extensible categories #56602
Description
| BPO | 12393 |
|---|---|
| Nosy | @vsajip, @tarekziade, @merwok |
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:
assignee = 'https://github.com/merwok'
closed_at = <Date 2014-03-13.02:45:45.135>
created_at = <Date 2011-06-24.08:53:25.039>
labels = ['type-feature', 'library']
title = 'Packaging should provide support for extensible categories'
updated_at = <Date 2014-03-13.02:45:45.134>
user = 'https://github.com/vsajip'bugs.python.org fields:
activity = <Date 2014-03-13.02:45:45.134>
actor = 'eric.araujo'
assignee = 'eric.araujo'
closed = True
closed_date = <Date 2014-03-13.02:45:45.135>
closer = 'eric.araujo'
components = ['Library (Lib)', 'Distutils2']
creation = <Date 2011-06-24.08:53:25.039>
creator = 'vinay.sajip'
dependencies = []
files = []
hgrepos = []
issue_num = 12393
keywords = []
message_count = 13.0
messages = ['138895', '138907', '138910', '138939', '138949', '138965', '144296', '145309', '145417', '145431', '153671', '153700', '153732']
nosy_count = 4.0
nosy_names = ['vinay.sajip', 'tarek', 'eric.araujo', 'alexis']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue12393'
versions = ['3rd party', 'Python 3.3']
Activity
vsajip commentedon Jun 24, 2011
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:
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.
merwok commentedon Jun 24, 2011
I think this should be part of the setup.cfg specification, not an install_data hook.
vsajip commentedon Jun 24, 2011
@É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 = path1
cat2 = path2
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 :-(
merwok commentedon Jun 24, 2011
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.
vsajip commentedon Jun 24, 2011
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
really about where to map appdata.* categories.
vsajip commentedon Jun 24, 2011
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.
merwok commentedon Sep 19, 2011
Can you add tests?
If there are many places that could benefit from such a function, we can add it.
vsajip commentedon Oct 10, 2011
https://bitbucket.org/vinay.sajip/pythonv/changeset/f7c5098e3c3b
merwok commentedon Oct 12, 2011
Great. Do you want to update the docs (packaging/setupscript and maybe packaging/commandref too) or shall I do it?
vsajip commentedon Oct 12, 2011
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.
merwok commentedon Feb 19, 2012
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.
vsajip commentedon Feb 19, 2012
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).
merwok commentedon Feb 19, 2012
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.