Bump tox from 4.11.4 to 4.12.0 #1606
Conversation
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
Bumps [tox](https://github.com/tox-dev/tox) from 4.11.4 to 4.12.0. - [Release notes](https://github.com/tox-dev/tox/releases) - [Changelog](https://github.com/tox-dev/tox/blob/main/docs/changelog.rst) - [Commits](tox-dev/tox@4.11.4...4.12.0) --- updated-dependencies: - dependency-name: tox dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
bot
added
dependencies
|
fwiw: #1262 (comment) may be easiest to continue masking |
Yeah... this is a hairy one. Masking FORCE_COLOR is definitely the expedient option. However, it then means that we lose the effect of FORCE_COLOR in the tox environment - so we won't have color output for anything run in tox. However, if you're running tests outside tox, and you have FORCE_COLOR set, the tests fail at present (e.g., I think I've got a handle on how we can do this cleanly; I'll tag you on a review if I can pull something together. |
|
Good deal; I'll just throw this out there as well...if we get pytest to set |
|
@rmartin16 Ok - I've got an approach that works. Let me know what you think. |
|
This makes sense to me once I'm able to take it in; given it is just for tests, though, it feels perhaps a bit intrusive... What are your thoughts on this? It requires another diff --git a/pyproject.toml b/pyproject.toml
index 01994b90..2e4b67e0 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -99,9 +99,10 @@ dev = [
"pre-commit == 3.5.0 ; python_version < '3.9'",
"pre-commit == 3.6.0 ; python_version >= '3.9'",
"pytest == 7.4.4",
+ "pytest-env == 1.1.3",
"pytest-xdist == 3.5.0",
"setuptools_scm == 8.0.4",
- "tox == 4.11.4",
+ "tox == 4.12.0",
]
docs = [
"furo == 2023.9.10",
@@ -225,6 +226,10 @@ multi_line_output = 3
[tool.pytest.ini_options]
testpaths = ["tests"]
+required_plugins = "pytest-env"
+env = [
+ # ensure Rich disables colored output
+ "TERM=dumb",
+]
filterwarnings = [
"error",
# suppress until python-dateutil>2.8.2 is released (https://github.com/dateutil/dateutil/issues/1284) |
Yeah... I agree it's more complex that I'd like. However, that's mostly because There might be a simpler approach that is based on Console instantiating an instance of Printer on first use - the PR will be larger (because it needs to work around all the existing singleton handling), but the final product should be easier to understand because it will be able to rely on simple attribute access and creation-time instantiation - which means the console itself could be configured to be "rich" for a single test.
Does this fix the problem though? Part of the reason that the solution is so baroque is that pytest imports the test module as part of discovery, which creates the Printer, which locks in the terminal interpretation. Does |
It fixes it for me on my Linux daily driver and my Windows 11 VM. I had quickly reviewed the Ultimately, though, I'm fine with either implementation. |
freakboy3742
force-pushed
the
dependabot/pip/tox-4.12.0
branch
from
21c5dc5
to
2330376
Compare
freakboy3742
force-pushed
the
dependabot/pip/tox-4.12.0
branch
from
2330376
to
e6a2841
Compare
|
@rmartin16 Ok - here's an alternate approach. I've made Printer not be a singleton. This means we no longer need the session cleanup handler, because the Console and Log objects are now created on every use; and they're also late instantiated, avoiding the environment problem. My inclination is that this is an architectural change that is beneficial regardless; and it has the added bonus that it defers the instantiation of the log instance, so we can use environment variables to control the instantiation. We could potentially even add tests for how the log handles environment variable, because each test will create a fresh Log instance. It also avoids a third-party plugin - while the pytest-env plugin doesn't look especially risky, my preference will always be to have less dependencies unless we're gaining significant functionality gains in exchange. Since we can get those gains by making an architectural change that is a good idea (IMHO) regardless, avoiding the plugin seems preferable. |
| printer = Printer() | ||
| console = Console(printer=printer) | ||
| logger = Log(printer=printer) |
There was a problem hiding this comment.
nitpick: Printer doesn't really need to be exposed up here in main; a console initialization function could wrap all this (and future logic) and return just the console and logger. (although, mostly indifferent if this happens now...or when future logic is added)
There was a problem hiding this comment.
Possibly - but that likely requires a either more comprehensive refactor so that Log and Console are more closely bound (or even merged entirely); introducing another wrapper object, or a single purpose "construct both" method, that really only avoids creating the printer. At least for now, my inclination is to leave this as is, and be explicit about the fact that there's a single printer, which both the log and the console may write to.
|
|
||
| @classmethod | ||
| def __call__(cls, *messages, stack_offset=5, show=True, **kwargs): | ||
| :param width: The width at which content should be wrapped. |
There was a problem hiding this comment.
nitpick: the uninitiated may be misled by this naming and description of width. It sounds like it'll affect both what's printed to the console and the log....while it's only relevant to the log.
There was a problem hiding this comment.
Agreed- I've tweaked the naming.
Bumps tox from 4.11.4 to 4.12.0.
Release notes
Sourced from tox's releases.
Changelog
Sourced from tox's changelog.
Commits
776718crelease 4.12.0fc80080Always pass FORCE_COLOR & NO_COLOR to the environment (#3172)659f714Fix the CI (#3183)8406971[pre-commit.ci] pre-commit autoupdate (#3182)3f8f53d[pre-commit.ci] pre-commit autoupdate (#3177)61547b0Fix 'open an issue' link in development.rst (#3179)328b348[pre-commit.ci] pre-commit autoupdate (#3176)383845a[pre-commit.ci] pre-commit autoupdate (#3166)d38c0e4Bump actions/setup-python from 4 to 5 (#3167)dace6ddBump pypa/gh-action-pypi-publish from 1.8.10 to 1.8.11 (#3164)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)