0

I have some tox project that processes some protobuf in the install-deps phase and outputs some *pb.py codecs (custom script executed as install_command option in the config). When I'm updating my workspace (and the protobuf files are updated), i would like to somehow mark the toxenv as invalid - so that it would get recreated without the need of passing -r, --recreate flags to some later tox call. I could add such action the the script that does the env update. Any idea on how to do it? i'm using some older tox - 3.14

sinoroc
  • 18,409
  • 2
  • 39
  • 70
murison
  • 3,640
  • 2
  • 23
  • 36
  • But *tox* re-installs (and re-builds) the project every time, right? I wonder how come that those `*pb.py` file are not generated as part of the build process of the project, instead of in the *tox* `install_command`. – sinoroc Feb 06 '23 at 15:34
  • extarnal stuff - not produced by tox. thats just an example - you could put any other kind of input files there. – murison Feb 06 '23 at 15:48

1 Answers1

0

turns out its described quite verbosly in the doc: https://tox.wiki/en/3.14.6/example/general.html?highlight=recreate#dependency-changes-and-tracking

Here’s what traits we track at the moment for each steps:

  • virtual environment trait is tied to the python path the basepython resolves too (if this config changes, the virtual environment will be recreated),
  • deps sections changes (meaning any string-level change for the entries, note requirement file content changes are not tracked),
  • library dependencies are tracked at extras level (because there’s no Python API to enquire about the actual dependencies in a non-tool specific way, e.g. setuptools has one way, flit something else, and poetry another).

Also from what i looked into tox code, here are the attributes that are checked https://tox.wiki/en/3.14.6/_modules/tox/venv.html?highlight=matches_with_reason

  • base_resolved_python_sha256
  • base_resolved_python_path
  • tox_version
  • sitepackages
  • usedevelop
  • alwayscopy

Apart from that, the first and most obvious way is to simply remove the <toxworkdir> dir on the env update. Other possibility can be to remove/rename the <toxenvdir>/.tox-config1 file.

murison
  • 3,640
  • 2
  • 23
  • 36