Tool: tox 4 on the horizon

Packaging
21

Okay, will do.

1 Like
22

I’ve tested it with pipx run --spec 'tox>4a' tox4, and it seems to work fine with all of my packages. (There was a scary moment or two, but it turns out a new mypy release had a legitimate complaint about my setup and the preexisting tox 3 environment just had an older mypy.)

I’m mildly surprised to see that the test command output is highlighted in red by default, because to me red in the terminal output means “error! pay attention!”

The output seems to be more verbose/cluttered by default, but I’m sure I’ll get used to it. Maybe.

So… good job!

2 Likes
23

Thanks for your feedback!

24

Just release it! That multi-year rewrite seems to never reach GA. If it was a business it would have being bankrupt one long time ago.

I love tox and your work on maintaining it. Still, the v4 excessive development cycle put the project in a situation where it deters new contributors. Even the few developers prone to contribute back are put down by the fact that they would have to propose a change to an unreleased version without any idea about when this will be available for others. I seen other projects being affected by the same kind of problem.

Basically this situation makes it harder to increase the number of active contributors and maintainers on the project, making your position even more critical with time. Unless maintainers likes being the weak link, I would argue for releasing often, even if is has know bugs. Minor patches after will address these and hopefully they will be fixed by others, not you.

The only moment when a software is “done” is when nobody else is using it anymore.

I happen to lead/maintain ansible-lint development, which has the same github popularity (stars) as tox and I had to make similar decisions about releasing a major version at least twice, even knowing that it contained lots of bugs, some signifiant. Yes, some people got upset but at the same time this revived the project, motivating others to contribute fixes. Slow adopters waited, sometimes even 6mo before upgrading to current release. Downstream distributions usually lag behind too, for the same reasons, as they would likely get upgraded only after several patch releases are made.

I wrote this because I do not want to see you collapse under maintenance burden. I care about the future of tox too. It is an awesome tool that only got much better in v4, the version I being using locally for a good number of months. I even had to add a `alias tox=“python -m tox” in order to overcome the problem related to “tox4” executable.

1 Like
25

Such a major release will ultimately break a lot of people, and we need maintainer availability to help those users and address their concerns. In the last 4 months I’ve been side tracked with some to be announced real life stuff and as such had no time available to dedicate to this. Things seem to resolve now, so post PyCon US this release might happen. But need to finish the new documentation first. We cannot do a release without documenting the changes. An open source project is not a business and as such cannot be handled/managed as such.

8 Likes
26

tox 4 is now out; see the (potential) breaking changes FAQ - tox and new features FAQ - tox :grinning:

1 Like
27

For the benefit of anyone else confused by the breaking changes FAQ,
the envvar for disabling color output is actually NO_COLOR=1 (based
on a quick inspection of the source code).

1 Like
28

Hey @bernatgabor congrats on the release! Just a quick question that I didn’t think warranted a full bug report. I help maintain Nox and one of the entry points is a very simple and naive tox-to-nox converter which relies on parsing the tox config. Currently (tox<4) we use the tox.config.parseconfig method to extract the Tox config and then render it through a Jinja template to naively turn it into a noxfile.py:

I’ve noticed that Tox 4 breaks this as it’s removed the method. I had a quick look through the Tox code but I’m not that familiar with it and couldn’t find any obvious replacement for this. Is there an equivalent to this method in Tox 4? I’ve constrained the version of Tox the tox-to-nox extra depends on in the meantime but would be good to continue to support this in the new version of Tox. Thanks again!

1 Like
29

I’m afraid what you’re looking for is no longer supported in tox 4. Primarily because tox 4 now supports content from other locations than tox.ini. Probably the best you can do is run tox config (see tox - CLI interface - tox ) and parse the INI representation from there.

2 Likes
30

That’s what I thought, thanks for confirming!

31

Has tox4 reversed the --skip-missing-interpreter behaviour? I have a very simple tox.ini shown below which used to fail on my local machine as I don’t have 3.8 installed. I updated to tox4 and all was good except the tests now pass after skipping py38. I am invoking tox simply as ‘tox’ from a shell script.

[tox]
envlist = py38,py39,py310,py311
isolated_build=true

[testenv]
deps =
    -rbuild/requirements-with-dev.txt
commands =
    pytest --cov=my_lovely_project --cov-append --cov-branch
32

@sonotley Indeed - this looks like a bug.

Could you please report this at our issue tracker?

~/Tests/test-tox-regressions via 🐍 v2.7.18 
❯ tox4
py312: skipped because could not find python interpreter with spec(s): py312
  py312: SKIP (0.01 seconds)
  evaluation failed :( (0.15 seconds)

~/Tests/test-tox-regressions via 🐍 v2.7.18 
❯ echo $?
0

~/Tests/test-tox-regressions via 🐍 v2.7.18 
❯ tox
py312 create: /home/jugmac00/Tests/test-tox-regressions/.tox/py312
ERROR: InterpreterNotFound: python3.12
_______________________________________________________________________ summary ________________________________________________________________________
ERROR:  py312: InterpreterNotFound: python3.12

~/Tests/test-tox-regressions via 🐍 v2.7.18 
❯ echo $?
1