Migrate ipfs v0.7.0 to v0.8.0 #112
Conversation
gammazero
commented
Nov 4, 2020
gammazero
commented
- Convert from mdag pinning to datastore pinning
gammazero
added
the
status/blocked
- Convert from mdag pinning to datastore pinning - Build ipfs command from specific commit (for now) - Require go1.14 in CI needed for above - Do not build using vendor dir
gammazero
force-pushed
the
feat/10-11-datastore-pins
branch
from
91d1287
to
197e400
Compare
go.mod
Outdated
| require ( | ||
| github.com/ipfs/go-blockservice v0.1.3 | ||
| github.com/ipfs/go-datastore v0.4.5 | ||
| github.com/ipfs/go-ds-flatfs v0.4.5 | ||
| github.com/ipfs/go-ds-leveldb v0.4.2 | ||
| github.com/ipfs/go-filestore v1.0.0 | ||
| github.com/ipfs/go-ipfs-blockstore v1.0.1 | ||
| github.com/ipfs/go-ipfs-exchange-offline v0.0.1 | ||
| github.com/ipfs/go-ipfs-pinner v0.0.5-0.20201029233447-cad837873ee6 | ||
| github.com/ipfs/go-ipld-format v0.2.0 | ||
| github.com/ipfs/go-merkledag v0.3.2 | ||
| golang.org/x/net v0.0.0-20200114155413-6afb5195e5aa | ||
| ) |
There was a problem hiding this comment.
@Stebalien WDYT is this fine for now and then we move to implementing #98, or should we just do that now?
There was a problem hiding this comment.
Note: there might be alternatives to #98 such as vendoring the dependencies and giving them all migration-specific names so we can keep everything in one binary, but I'm not sure if they'd be any better.
There was a problem hiding this comment.
We can't have unvendored deps in this repo but we could try using go mod vendoring.
There was a problem hiding this comment.
The go mod vendor command constructs a directory named vendor in the main module's root directory that contains copies of all packages needed to support builds and tests of packages in the main module.
Is the suggestion to make new packages + go.mod's in each migration and then to try and vendor, or to copy the approach from the migrations before we were using gx.
This is done by turning the ipfs-10-to-11 migration into its own module and vendoring its dependencies using go mod vendor. Since this makes ipfs-10-to-11 an independent module, and no longer a package within the fs-repo-migrations module, it changes how to build it. The top level fs-repo-migrations module must now require the ipfs-10-to-11 module in its go.mod, and then use a replace direct so that it does not actually need to download that module from github (or find it in the vendor directory). The sharness tests must also build it as a separate module and not as a package within the fs-repo-migrations module.
|
I've manually vendored the deps. |
|
One of the problems with using go modules for vendoring the dependencies of I think the correct solution to this is presented in #98 which gets rid of the monolithic fs-repo-migrations binary. As a temporary solution |
|
Note: Needed to update go version in top-level go.mod to |
gammazero
added
status/blocked
gammazero
force-pushed
the
feat/10-11-datastore-pins
branch
from
e70d220
to
1024b44
Compare
aschmahmann
removed
the
status/blocked
