search

wallento / wavedrompy

WaveDrom compatible python command line
Other
97 stars 23 forks source link

Freeze upstream version #26

Closed MutantPlatypus closed 2 years ago

MutantPlatypus commented 4 years ago

As identified in the comments to PR #23, a change upstream at 1d4d251 causes the upstream tests to fail. Until a fix is implemented in this project to match upstream behavior, testing will be limited to the commit before 1d4d251.

To see for yourself, add -x to the tox test command (to save yourself from the huge xml diff log):

commands =
    pytest -v {posargs} -x

and remove that ~1 from the git hash. It looks like it's just a quirk of how the SVG is encoding because every file fails. Even the ones that didn't use the new background colors. Almost like those colors were defined in some sort of style or entity definition, and that's what's throwing off your diff?

MutantPlatypus commented 4 years ago

I think I would prefer to place this in a variable at the top of the file, but I didn't because I would really prefer to use conda or the shell to provision this at a higher level. When running this way, each venv/tox environment:

  1. Clones the wavedrom repo.
  2. Installs wavedrom with NPM.
  3. Renders each test file to SVG.
  4. Rasterizes each test file to PNG.

It does this for each environment, which isn't needed because the four above tasks 1-3 don't use Python, and the 4th one isn't a test of wavedrompy. This turns pytest-xdist into a huge performance penalty (each session runs that fixture setup) when it really could help a lot if we did the four above steps outside of pytest.

EDIT: Unless [tox-run-before](https://github.com/praekelt/tox-run-before) works the way it says it does, there isn't an easy way to do this with a single call to tox, though. It would have to be scripted with a "provision_test_env.py" script, and then pytest can just verify the version of wavedrom hasn't gone stale somehow. When provisioning, I could use that "WAVEDROMDIR" environment variable that you are already using...but I'm not sure how to prevent it from going stale. Might still have to emit a git hash to the environment while provisioning, and check it during pytest fixturing.