This adds a plugin interface that lets the plugin modify the fx
options that are passed to fx when the app is initialized. This means
plugins can inject their own implementations of IPFS interfaces. This
enables granular customization of go-ipfs behavior by plugins, such
as:
- Bitswap with custom filters (e.g. for CID blocking) Custom interface
- implementations such as Pinner or DAGService
- Dynamic configuration of libp2p ...
One downside of this is that we're exposing the entire dependency
graph, init hooks, initialization, etc. to users, so this comes with a
caveat that we reserve the right to make breaking changes to the graph
structure and initialization logic (although this historically happens
rarely). If these things are changed, we should mention them in
release notes and changelogs though, since they could impact users of
this plugin interface.
I'm not particularly fond of DI frameworks (and neither are some of
the folks work on/near go-ipfs), but it seems unlikely that somebody
will rewrite the dependency wiring and lifecycle hooks of go-ipfs, and
add dynamic extension points, so this seems like a palatable
compromise.
There are also problems that we should clean up in how model the
go-ipfs app in fx, such as:
- We make extensive use of nested fx.Options, which fx itself
discourages because it "limits the user's ability to customize their
application". It should be easy to flatten these out into a single
[]fx.Option slice.
- We pass around a list of opaque libp2p opts, which makes it hard to
customize after-the-fact...we should consider naming each of these
opts and providing them to fx as proper dependencies, so that they can
be explicitly overridden.
- We call fx.Invoke() in some places with anonymous functions. We
should instead only pass exported functions to fx.Invoke(), so that
they have exported names, which would make it easier to remove/augment
the invocations that happen when the app is initialized.
These aren't blocking issues, they just make it harder and more
brittle to customize go-ipfs with this plugin.
Instead of feeding through the top-level context, feed through a cancel-free
context (that still carries the same context values). Then, when the top-level
context is canceled, call `stop` to shut everything down in-order. Finally,
cancel the inner context to make sure everything has been cleaned up.
Ideally, we just wouldn't use contexts for this. But this is strictly better
than what we have.
Most of these are probably harmless but a few looked like they might actually be
bugs. Most of them are just faulty tests.
License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
1. They don't _have_ to be mutually exclusive.
2. local, mode, etc is _really_ confusing.
License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
Switch _back_ to the 0.4.18 style of peer IDs while we figure things out. See
https://github.com/libp2p/specs/issues/138.
License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
Loading this at the last minute means we need a bunch of special cases
in *every* command that needs routing, namesys, or even the public key.
If we ever have a case where we don't want to do this, we can add an option to
the (eventual) IPFS constructor. Handling this up-front is going to be
significantly less error prone.
Motivation: https://github.com/ipfs/go-ipfs/pull/5825/files#diff-fe35ea64d478c4f3fb767a3f618e5d01R863
License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
