Currently the "path" module does two very different things:
* Defines how ipfs paths look like and provides tools to parse/split etc.
* Provides a resolver to resolve paths.
This moves the resolver stuff to `path/resolver` and leaves the
path utilities in `path`.
The result is that now the IPFS `path` package just defines what a path
looks like and becomes a module that can be exported/re-used without problems.
Currently there are circular dependency cycles (resolve_test -> merkledag/utils,
merkledag->path), which the prevent the export of merkledag itself.
License: MIT
Signed-off-by: Hector Sanjuan <hector@protocol.ai>
The new coreiface.Path maps a path to the cid.Cid
resulting from a full path resolution.
The path is internally represented as a go-ipfs/path.Path,
but that doesn't matter to the outside.
Apart from the path-to-CID mapping, it also aims to hold all
resolved segment CIDs of the path. Right now it only exposes
Root(), and only for flat paths a la /ipfs/Qmfoo. In other cases,
the root is nil.
In the future, resolution will internally use
go-ipfs/path.Resolver.ResolvePathComponents and thus always return
the proper resolved segments, via Root(), or a future Segments() func.
- Add coreiface.Path with Cid() and Root().
- Add CoreAPI.ResolvePath() for getting a coreiface.Path.
- All functions now expect and return coreiface.Path.
- Add ParsePath() and ParseCid() for constructing a coreiface.Path.
- Add coreiface.Node and Link which are simply go-ipld-node.Node and Link.
- Add CoreAPI.ResolveNode() for getting a Node from a Path.
License: MIT
Signed-off-by: Lars Gierth <larsg@systemli.org>
