Skip to content
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

Move/rename repo #146

Open
Stebalien opened this issue Oct 31, 2022 · 1 comment
Open

Move/rename repo #146

Stebalien opened this issue Oct 31, 2022 · 1 comment

Comments

@Stebalien
Copy link
Member

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.

@anorth
Copy link
Member

anorth commented Oct 31, 2022

I gather there is a third leg to the dependency detour here, where

  • FVM, or at least some of your development processes, depend on built-in actors.

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 next branch 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:

  • hosting all FRC-related code in filecoin-project
  • preferencing some FRC-related impls over others in filecoin-project

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants