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 1 commit
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`.
48 changes: 48 additions & 0 deletions docs/upgrading.rst
Expand Up @@ -149,3 +149,51 @@ Re-use of environments

[testenv:b]
deps = pytest<7


Legacy CLI entry point may result in ambiguous usages
Copy link
Member

Choose a reason for hiding this comment

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

Probably should be shorter: CLI compatibility is enough.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There's another section on "CLI arguments", so I called it "CLI command compatibility", but we could also combine the sections later maybe.

-----------------------------------------------------

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

As a result, commands which were previously unambiguous may have become ambiguous.

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.

Under ``tox`` 4, this usage parses as an invocation of ``tox list``.
Therefore, attempting that same usage results in an error:

.. code:: bash

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

It can be run either with an explicit ``tox run`` or an explicit use of the
legacy command:
sirosen marked this conversation as resolved.
Show resolved Hide resolved

.. 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...

$ tox legacy -e list