Repository navigation
Move/rename repo #146
Description
Given that this is shaping up to be a core shared library, it should live in the filecoin-project org:
- Either as a sub-crate in the builtin actors.
- Or as a new package? Maybe something like librfc?....
- Or something in the ref-fvm repo?
Right now, there's an awkward dependency detour where:
- The builtin actors depend on this repo.
- This repo depends on the FVM.
Most changes to the FVM's API will require a change change in this repo before that change can be propagated to the builtin actors. This will be a non-issue once M2.2 (general programmability) ships as the FVM interfaces will have stabilized by then (or we'll have proper FVM "container" versioning, at the very least). But the current situation won't work for M2.1 and M2.2 because we're actively changing said interfaces.
Activity
anorth commentedon Oct 31, 2022
I gather there is a third leg to the dependency detour here, where
Otherwise, this would be a straightforward propagation and I don't see why FVM team would care.
What does that dependency look like, and is there any way to break it? Otherwise this is going to be quite awkward anyway, even if you have control of all three legs.
Another option is forking this repo into filecoin-project. At least for
nextbranch work this would give you the control you need – e.g. you could depend on git hashes rather than published crates. Then changes you make in the fork can be propagated back to a mainline that lives here.Another option is wholesale copying the code (with attribution) into the builtin-actors repo, for its use there, and dropping dependency on published crates. But still expect all user-programmed actors to use this repo and its artefacts.
In both cases, a decision about whether or not the builtin actors switch back to published crates later can be deferred a bit.
I spent some time trying to determine the right place for this code before we started. General agreement was that code built primarily by community teams should live in their orgs. It wasn't obvious to me that the time that the built-in actors would depend on it directly, and I could see good arguments why we should minimise external dependencies there. However think we should try to avoid setting a precedent for:
Stebalien commentedon Mar 26, 2025
I've at least partially fixed this dependency detour by removing the cargo dependency on the built-in actors. Instead, we download the pre-built bundle from github and use that. This means there is no circular dependency between this crate and the built-in actors.