-
Notifications
You must be signed in to change notification settings - Fork 804
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
Grouping podman build
options
#4431
Comments
Can you give me an example of a command line tool that does this? |
pip install -h Usage:
pip install [options] <requirement specifier> [package-index-options] ...
pip install [options] -r <requirements file> [package-index-options] ...
pip install [options] [-e] <vcs project url> ...
pip install [options] [-e] <local project path> ...
pip install [options] <archive url/path> ...
Description:
Install packages from:
- PyPI (and other indexes) using requirement specifiers.
- VCS project urls.
- Local project directories.
- Local or remote source archives.
pip also supports installing from "requirements files", which provide
an easy way to specify a whole environment to be installed.
Install Options:
-r, --requirement <file> Install from the given requirements file. This
option can be used multiple times.
-c, --constraint <file> Constrain versions using the given constraints
file. This option can be used multiple times.
--no-deps Don't install package dependencies.
--pre Include pre-release and development versions. By
default, pip only finds stable versions.
-e, --editable <path/url> Install a project in editable mode (i.e.
setuptools "develop mode") from a local project
path or a VCS url.
--dry-run Don't actually install anything, just print what
would be. Can be used in combination with
--ignore-installed to 'resolve' the
requirements.
-t, --target <dir> Install packages into <dir>. By default this
will not replace existing files/folders in
<dir>. Use --upgrade to replace existing
packages in <dir> with new versions.
--platform <platform> Only use wheels compatible with <platform>.
Defaults to the platform of the running system.
Use this option multiple times to specify
multiple platforms supported by the target
interpreter.
--python-version <python_version>
The Python interpreter version to use for wheel
and "Requires-Python" compatibility checks.
Defaults to a version derived from the running
interpreter. The version can be specified using
up to three dot-separated integers (e.g. "3" for
3.0.0, "3.7" for 3.7.0, or "3.7.3"). A major-
minor version can also be given as a string
without dots (e.g. "37" for 3.7.0).
--implementation <implementation>
Only use wheels compatible with Python
implementation <implementation>, e.g. 'pp',
'jy', 'cp', or 'ip'. If not specified, then the
current interpreter implementation is used. Use
'py' to force implementation-agnostic wheels.
--abi <abi> Only use wheels compatible with Python abi
<abi>, e.g. 'pypy_41'. If not specified, then
the current interpreter abi tag is used. Use
this option multiple times to specify multiple
abis supported by the target interpreter.
Generally you will need to specify
--implementation, --platform, and --python-
version when using this option.
--user Install to the Python user install directory for
your platform. Typically ~/.local/, or
%APPDATA%\Python on Windows. (See the Python
documentation for site.USER_BASE for full
details.)
--root <dir> Install everything relative to this alternate
root directory.
--prefix <dir> Installation prefix where lib, bin and other
top-level folders are placed
--src <dir> Directory to check out editable projects into.
The default in a virtualenv is "<venv
path>/src". The default for global installs is
"<current dir>/src".
-U, --upgrade Upgrade all specified packages to the newest
available version. The handling of dependencies
depends on the upgrade-strategy used.
--upgrade-strategy <upgrade_strategy>
Determines how dependency upgrading should be
handled [default: only-if-needed]. "eager" -
dependencies are upgraded regardless of whether
the currently installed version satisfies the
requirements of the upgraded package(s). "only-
if-needed" - are upgraded only when they do not
satisfy the requirements of the upgraded
package(s).
--force-reinstall Reinstall all packages even if they are already
up-to-date.
-I, --ignore-installed Ignore the installed packages, overwriting them.
This can break your system if the existing
package is of a different version or was
installed with a different package manager!
--ignore-requires-python Ignore the Requires-Python information.
--no-build-isolation Disable isolation when building a modern source
distribution. Build dependencies specified by
PEP 518 must be already installed if this option
is used.
--use-pep517 Use PEP 517 for building source distributions
(use --no-use-pep517 to force legacy behaviour).
--check-build-dependencies Check the build dependencies when PEP517 is
used.
--config-settings <settings>
Configuration settings to be passed to the PEP
517 build backend. Settings take the form
KEY=VALUE. Use multiple --config-settings
options to pass multiple keys to the backend.
--install-option <options> Extra arguments to be supplied to the setup.py
install command (use like --install-option="--
install-scripts=/usr/local/bin"). Use multiple
--install-option options to pass multiple
options to setup.py install. If you are using an
option with a directory path, be sure to use
absolute path.
--global-option <options> Extra global options to be supplied to the
setup.py call before the install or bdist_wheel
command.
--compile Compile Python source files to bytecode
--no-compile Do not compile Python source files to bytecode
--no-warn-script-location Do not warn when installing scripts outside PATH
--no-warn-conflicts Do not warn about broken dependencies
--no-binary <format_control>
Do not use binary packages. Can be supplied
multiple times, and each time adds to the
existing value. Accepts either ":all:" to
disable all binary packages, ":none:" to empty
the set (notice the colons), or one or more
package names with commas between them (no
colons). Note that some packages are tricky to
compile and may fail to install when this option
is used on them.
--only-binary <format_control>
Do not use source packages. Can be supplied
multiple times, and each time adds to the
existing value. Accepts either ":all:" to
disable all source packages, ":none:" to empty
the set, or one or more package names with
commas between them. Packages without binary
distributions will fail to install when this
option is used on them.
--prefer-binary Prefer older binary packages over newer source
packages.
--require-hashes Require a hash to check each requirement
against, for repeatable installs. This option is
implied when any package in a requirements file
has a --hash option.
--progress-bar <progress_bar>
Specify whether the progress bar should be used
[on, off] (default: on)
--root-user-action <root_user_action>
Action if pip is run as a root user. By default,
a warning message is shown.
--report <file> Generate a JSON file describing what pip did to
install the provided requirements. Can be used
in combination with --dry-run and --ignore-
installed to 'resolve' the requirements. When -
is used as file name it writes to stdout.
--no-clean Don't clean up build directories.
Package Index Options:
-i, --index-url <url> Base URL of the Python Package Index (default
https://pypi.org/simple). This should point to a
repository compliant with PEP 503 (the simple
repository API) or a local directory laid out in
the same format.
--extra-index-url <url> Extra URLs of package indexes to use in addition
to --index-url. Should follow the same rules as
--index-url.
--no-index Ignore package index (only looking at --find-
links URLs instead).
-f, --find-links <url> If a URL or path to an html file, then parse for
links to archives such as sdist (.tar.gz) or
wheel (.whl) files. If a local path or file://
URL that's a directory, then look for archives
in the directory listing. Links to VCS project
URLs are not supported.
General Options:
-h, --help Show help.
--debug Let unhandled exceptions propagate outside the
main subroutine, instead of logging them to
stderr.
--isolated Run pip in an isolated mode, ignoring
environment variables and user configuration.
--require-virtualenv Allow pip to only run in a virtual environment;
exit with an error otherwise.
-v, --verbose Give more output. Option is additive, and can be
used up to 3 times.
-V, --version Show version and exit.
-q, --quiet Give less output. Option is additive, and can be
used up to 3 times (corresponding to WARNING,
ERROR, and CRITICAL logging levels).
--log <path> Path to a verbose appending log.
--no-input Disable prompting for input.
--proxy <proxy> Specify a proxy in the form
scheme://[user:passwd@]proxy.server:port.
--retries <retries> Maximum number of retries each connection should
attempt (default 5 times).
--timeout <sec> Set the socket timeout (default 15 seconds).
--exists-action <action> Default action when a path already exists:
(s)witch, (i)gnore, (w)ipe, (b)ackup, (a)bort.
--trusted-host <hostname> Mark this host or host:port pair as trusted,
even though it does not have valid or any HTTPS.
--cert <path> Path to PEM-encoded CA certificate bundle. If
provided, overrides the default. See 'SSL
Certificate Verification' in pip documentation
for more information.
--client-cert <path> Path to SSL client certificate, a single file
containing the private key and the certificate
in PEM format.
--cache-dir <dir> Store the cache data in <dir>.
--no-cache-dir Disable the cache.
--disable-pip-version-check
Don't periodically check PyPI to determine
whether a new version of pip is available for
download. Implied with --no-index.
--no-color Suppress colored output.
--no-python-version-warning
Silence deprecation warnings for upcoming
unsupported Pythons.
--use-feature <feature> Enable new functionality, that may be backward
incompatible.
--use-deprecated <feature> Enable deprecated functionality, that will be
removed in the future. |
|
@abitrolly I see what you mean, I think we can do this since cobra already has a support for this afaics https://github.com/spf13/cobra/blob/main/user_guide.md#grouping-commands-in-help . Lets see if everybody likes this idea. @nalind @rhatdan WDYT ? |
@flouthoc option groups are is not supported in cobra yet spf13/cobra#1778 |
@abitrolly Ah I see then lets wait for this feature. |
Nice, but surprised it is not alphabetic. |
@flouthoc or switch to the lib that already supports this urfave/cli#1368 |
Switching the libraries is not an option. There are lot of great feature in cobra we make use of and the amount of work needed to switch (without regressions) is just insane. Also you could totally implement this already in cobra by using a custom help template. However in general I don't really see the need why the --help output needs this, wouldn't it be better if the man page is sorted in groups? And maybe the more interesting question what groups should this command have? |
I don't know who reads man pages. There is no data on that. |
I need all options related to debugging grouped together. Logging levels, filtering by component, writing to a parallel stream. So that I can quickly debug what is going on with #4423 |
I don't think the amount of work is insane. If |
Then I suggest you prove this by opening a PR. |
I don't use cobra, and I don't know if it can do this to prove it. |
A friendly reminder that this issue had no activity for 30 days. |
Well unless someone opens a PR to add this or figures an easy way to do this with Cobra, I am going to close. |
Description
podman build
help contains 91 option, and contains 10k of text. It is quite straining to scan these to find out which can be used to debugging (things like #4423) and for other purposes. Splitting options in groups would help makingpodman
UX more enjoyable.Describe the results you expected:
At least one group related to logging/debug.
The text was updated successfully, but these errors were encountered: