FM-106: Upgrade FVM version to 3.4 #109
Conversation
aakoshh
changed the title
| # The following are on crates.io but they might be pre-releases. | ||
| fvm = { version = "3.1", default-features = false } # no opencl feature or it fails on CI | ||
| fvm_shared = { version = "3.1", features = ["crypto"] } | ||
| # Depending on the release cycle, this dependency might want an earlier version of the FVM. |
There was a problem hiding this comment.
I don't know if we will regret it in the long-run, but something we could do is to bring all the frc42 that we need to https://github.com/consensus-shipyard/fvm-utils, so we can upgrade accordingly. This is the approach we are following for actor runtimes. We also use extensively frc42 in actors, so maybe this helps. Instead of using the external dependency we can fork the relevant code that we need into our fvm-utils.
(Been there, and I hate this dependency dance, is a time drain)
There was a problem hiding this comment.
Hm, I didn't know you use it that much. It was released last month, so it doesn't seem to lag that much. Would it be possible to jump in and do a release, could they just be busy?
But yeah, if there is pain, we have that option too. I don't follow what features there are in the FVM releases, so I'm not sure we need to be on the bleeding edge. For now I think we can save ourselves the extra burden.
Closes consensus-shipyard/ipc#341
We can upgrade to 3.2, but to go to 3.3 or 3.4 is thwarted by
frc42_dispatchdepending on 3.2We can try to remove that dependency by hardcoding the hash, like the FVM integration tests do 😣
We only have 1 method to hash, so this isn't too bad at the moment, but if in the future there would be more, I would switch back to using the hasher.
Perhaps it was a one-off, but the test times were faster without this dependency (the 3.2 and 3.4 tests were running concurrently, so it's not down to caching).