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!

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.

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.

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.

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

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 :