| msg94453 - (view) |
Author: Zooko O'Whielacronx (zooko) |
Date: 2009-10-25 14:37 |
| This command: python setup.py --verbose darcsver works as expected -- the presence of '--verbose' increases the verbosity of logging. This command: python setup.py darcsver --verbose does not increase the verbosity, nor does it tell me that the "--verbose" option is an option unknown to the "darcsver" command. This command: python setup.py darcsver --quux gives this helpful output: usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: option --quux not recognized I think that the middle command ("python setup.py darcsver --verbose") ought to behave either like the first command by increasing the verbosity, or like the last command by telling the user that "--verbose" is not a known option in that position. This is also http://bitbucket.org/tarek/distribute/issue/78/ |
|
|
| msg94518 - (view) |
Author: Tarek Ziadé (tarek) *  |
Date: 2009-10-26 22:00 |
| There's this comment in dist.py: # All commands support the global options too, just by adding # in 'global_options'. So, that's a bug. I'll do this: - if a command has a global option (except help) it will be reapplied to the distribtuion object - if a command has a global option (except help) but also defines it as a local command option, it will not be reapplied to the distribtuion object - if a command has a global option (except help) and it was already provided at the regular place, it will be ignored and a warning will be displayed. |
|
|
| msg221731 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2014-06-27 20:59 |
| Assuming that this is still an issue would someone like to propose a patch? |
|
|
| msg346891 - (view) |
Author: Avinash Sajjanshetty (avi) * |
Date: 2019-06-29 17:50 |
| I would like to take this up task and propose a patch. However, I am not able to reproduce this issue on my machine (3.7.1). Does the issue seem to be fixed? Here is what I tried: 1. python setup.py --verbose build I got the verbose build, as expected. 2. python setup.py build --verbose In this case, it seems to have ignored the verbose option, as I got a normal (non-verbose) output. 3. since the issue is with `verbose`, I tried quiet. python setup.py --quiet build I got a quiet build. 4. python setup.py build --quiet it ignored the quiet option, as I got a normal output. 5. I also tried a non-existent option. In the following both cases, I got an error saying error: option --qqqp not recognized for python setup.py --qqqp build and python setup.py build --qqqp |
|
|
| msg347802 - (view) |
Author: Milan Oberkirch (zvyn) * |
Date: 2019-07-13 10:42 |
| The help states: > usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] so I would argue that setup.py ignoring global_opts after cmd1 is not a bug. But I do think that the fact that "python setup.py build --dry-run" does not prevent the build from running is not ideal. Maybe throwing an error for misplaced global options is the best solution? |
|
|
| msg347999 - (view) |
Author: Giovanni Cappellotto (potomak) * |
Date: 2019-07-16 02:35 |
| I took a stab at this, see attached PR. I was able encode the first two cases described by @tarek, but not the first one because `_parse_command_opts` doesn't have visibility to the list of global options that have already been parsed. Note: I had to move `log.set_verbosity(self.verbose)` after the call to `_parse_command_opts` in order to correctly apply the verbosity level after all command options are parsed. I think there should be a better way to handle this case, maybe by creating a `verbose` setter that re-runs `log.set_verbosity` every time `verbose` value is updated. |
|
|
| msg386286 - (view) |
Author: Steve Dower (steve.dower) * |
Date: 2021-02-03 18:10 |
| Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils. If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools |
|
|