wasmtime-py 0.16.1 regression

[whitequark]

Unfortunately since 0.16.1 it looks like every binary crashes on exit:

Traceback (most recent call last):
  File "/home/whitequark/.local/bin/yosys", line 11, in <module>
    load_entry_point('yosys', 'console_scripts', 'yosys')()
  File "/home/whitequark/Projects/yosys-pypi/yosys/__init__.py", line 57, in _run_yosys_argv
    run_yosys(sys.argv)
  File "/home/whitequark/Projects/yosys-pypi/yosys/__init__.py", line 55, in run_yosys
    _run_wasm_app("yosys.wasm", argv)
  File "/home/whitequark/Projects/yosys-pypi/yosys/__init__.py", line 51, in _run_wasm_app
    app.exports["_start"]()
  File "/home/whitequark/.local/lib/python3.7/site-packages/wasmtime/_func.py", line 120, in __call__
    raise Trap.__from_ptr__(trap)
wasmtime._trap.Trap: explicitly exited

[whitequark]

Actually I'm not sure if it's a regression, I can't consistently reproduce it for some reason?..

[alexcrichton]

This is due to bytecodealliance/wasmtime#1646, and I think we need to enhance the C API with accessors to see if something exited, so bindings can be added for "was this an exit trap" and the trap can be raised with a different error perhaps.

[whitequark]

Sounds good. I wonder if maybe 0.16.1 should be yanked as it broke published nmigen-yosys packages; that's not super important at the moment since nothing depends on them yet, but I do plan to actually rely on wasmtime-py in near future, and I'd like to be able to use semver in that case.

[alexcrichton]

Hm ok I'm fine going either way, what would you prefer?

My main thinking is that I would like this package to track the versioning of upstream wasmtime to help alleviate versioning woes.

[whitequark]

My main thinking is that I would like this package to track the versioning of upstream wasmtime to help alleviate versioning woes.

Unless I'm missing something, doesn't the version already not match upstream? The latest wasmtime version is 0.16.0, the wasmtime-py vesion is currently 0.16.1, and the actual wasmtime binary inside is produced from the dev branch, which is neither this nor that:

wasmtime-py/download-wasmtime.py

Line 31 in cc07955

url = 'https://github.com/bytecodealliance/wasmtime/releases/download/dev/'

[whitequark]

Something that is relevant here is that PyPI versions have a concept called "post-release", where you can use a version 0.16.0.post1 to indicate "the 0.16.0 tag plus some changes". Unfortunately it doesn't quite solve the problem alone because there is no easy way to disambiguate "the changes were in wasmtime" and "the changes were in wasmtime-py". There is a more complex variant of this scheme I'm using in other projects which I can describe in detail if you're interested.

[alexcrichton]

Oh sorry I mean moreso the "major" version changes in lockstep with wasmtime, but patch releases are always fine to ship whenever. It's true that the latest version is always downloaded, but that's mostly because I'm imperfect and doing something otherwise is just a pain.

I dunno I don't really know how best to manage the versions here. I can't really dedicate all of my time to this extension, so I'm trying to set up processes that are at least easy to follow. If you'd like I'm happy to yank, but it means that the windows fixes won't be in until 0.17, but it shouldn't be hard to make an 0.17 release of wasmtime upstream.

[whitequark]

Got it, that's fine.

Let's yank because going from "working on Linux/macOS but broken on Windows" to "uniformly broken on every platform even though semver says it should be compatible" is worse than just the status quo.

[whitequark]

Also doesn't using the dev tag means that the builds are inherently irreproducible? I don't personally find that a concern as long as everything works but I can see some packaging folks taking an issue with it.

[alexcrichton]

Ok! I've gone ahead and yanked the build.

Yes it would probably be good to at least record where the dev tag comes from (e.g. a git sha), but given the git sha of wasmtime itself it's as reproducible as Rust generally is.

[whitequark]

Yeah, the only issue is the tag itself.