-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(lib/runtime): CheckRuntimeVersion
independent from existing runtime instance
#2687
Changes from all commits
6cac143
0e089f0
8190fd8
754be03
d7e0ad1
6bce0f6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand why you removed this function from the interface since it creates a new instance to do the version check, but how will we mock this out now? We'd have to change the function signatures of all callers of this function to include a
func([]byte) (Version, error)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say it's better to not mock it, since:
If you still want to mock it somewhere though, then you can set it as a functional field on the receiving struct like
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's fast at all. It's instantiating a wasmer instance, loading the code in, binding the imports, etc. Now all of the unit tests are runtime specific if we remove it from the
Instance
interface.Why aren't we just implementing a
RuntimeVersion() (Version, error)
(no blob) onInstance
. Then anyone who needs to version check needs to instantiate an instance viaNewInstance
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It takes 500ms to load the version, so not that fast indeed.
But if you have a look, there was no configuration of the
CheckRuntimeVersion
mock method expectation, so it won't change a thing with our code as it is.And as I mentioned above, if in the future we want to mock the runtime check (for test coverage or testing speed), we can just set it as a field on the receiving struct (like we would with
timeNow func() time.Time
to mock time).Also (in my opinionated opinion), having a function as a method just for the sake of it being part of an interface for testing is a bit weird, especially if it doesn't depend on the struct/implementation at all (wasn't the case before though, but it is now).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked at the interface again. The
Instance
interface includes aVersion() (Version, error)
method. I think we should removeCheckRuntimeVersion
from the runtime package and make this a private method indot/state
and a helper function for the tests. What do you think?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, although that would require to export a bunch of things such as
setupVM
, the wasmerInstance
struct fieldsvm
andctx
, and I think ultimately we should keep this in the wasmer package since it's quite tightly coupled with wasmer thingies? I would rather exportCheckRuntimeVersion
than these other function/fields, what do you think?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do you need to export those private functions? To check a version of a given wasm blob, you instantiate an instance by calling
NewInstance(code []byte, cfg runtime.InstanceConfig)
and callVersion()
on that instance.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, sorry I misunderstood.
I changed
CheckRuntimeVersion
to useNewInstance
, simplifying it a bit / reducing code duplication (although it sets up extra stuff it doesn't need, but that's a dep injection problem for another day).On the other hand,
ext_misc_runtime_version_version_1
inwasmer/imports.go
usesCheckRuntimeVersion
so I think we should still keep it in the wasmer package? 🤔There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have dissonance with having a function on the public package API that achieves the same functionality that can be achieved by instantiating an instance and calling a receiver method on that instance. But that would lead to code duplication cause we use it in various places. I gave it a shot in this commit, and I'm not really happy with it. So I'm ok with leaving with leaving it in the
wasmer
package.