Skip to content
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

Document ambiguous usages in v3-to-v4 #2808

Merged
merged 2 commits into from Jan 3, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
1 change: 1 addition & 0 deletions docs/changelog/2728.doc.rst
@@ -0,0 +1 @@
Document how to handle environments whose names match ``tox`` subcommands - by :user:`sirosen`.
73 changes: 73 additions & 0 deletions docs/upgrading.rst
Expand Up @@ -149,3 +149,76 @@ Re-use of environments

[testenv:b]
deps = pytest<7


CLI command compatibility
-------------------------

``tox`` 4 introduced dedicated subcommands for various usages.
However, when no subcommand is given the legacy entry point which imitates ``tox`` 3 is used.

This compatibility feature makes most ``tox`` 3 commands work in ``tox`` 4, but there are some exceptions.

Updating usage with ``-e``
++++++++++++++++++++++++++

In ``tox`` 3, environments could be specified to run with the ``-e`` flag.
In ``tox`` 4, environments should always be specified using the ``-e`` flag to the ``run`` subcommand.

Rewrite usages as follows

.. code:: bash

# tox 3
tox -e py310,style

# tox 4
tox run -e py310,style

# or, tox 4 with the short alias
tox r -e py310,style

Environment names matching commands
+++++++++++++++++++++++++++++++++++

Now that ``tox`` has subcommands, it is possible for arguments to ``tox`` or its options to match those subcommand
names.
When that happens, parsing can become ambiguous between the ``tox`` 4 usage and the legacy fallback behavior.

For example, consider the following tox config:

.. code-block:: ini

[tox]
env_list = py39,py310

[testenv]
commands =
python -c 'print("hi")'

[testenv:list]
commands =
python -c 'print("a, b, c")'

This defines an environment whose name matches a ``tox`` 4 command, ``list``.

Under ``tox`` 3, ``tox -e list`` specified the ``list`` environment.
However, under ``tox`` 4, the parse of this usage as an invocation of ``tox list`` takes precedence over the legacy
behavior.

Therefore, attempting that same usage results in an error:

.. code:: bash

$ tox -e list
...
tox: error: unrecognized arguments: -e

This is best avoided by updating to non-legacy usage:

.. code:: bash

$ tox run -e list
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For what's worth this is my recommended way to run unambiguous command names too, so let's State that. Assuming legacy by default is just a backwards compatibility layer and might be removed with tox 5.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth mentioning that you don't have to type run fully, the r letter acts as a shorter alias 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I'll come back to you with something that states that more clearly, and we can wordsmith it more if necessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In order to put this front-and-center, I decided to split the section up a little more.
First it states that you should rewrite any use of tox -e foo to tox run -e foo/tox r -e foo without trying to explain why. The second subsection focuses on the bad case of an environment matching a command name.

Hope you like it this way!


# or, equivalently...
$ tox r -e list