IPLD Prime In IPFS: Target Merge Branch #36

hannahhoward · 2021-04-02T18:09:32Z

Official merge branch for IPLD Prime In IPFS effort.

Switches usage over to go-fetcher

See: #34

aschmahmann

Still working my way through the libraries and some of the issues I raise might come lower down the stack, but wanted to get a few thoughts out there while I'm still reviewing.

aschmahmann · 2021-04-14T06:54:22Z

resolver/resolver.go

-	DAG ipld.NodeGetter
-
-	ResolveOnce ResolveOnce
+	FetchConfig fetcher.FetcherConfig


What's the advantage of exposing this as a fetcher.FetcherConfig struct as opposed to some interface?

Perhaps this question is really about go-fetcher, but it looks like in the non-test code here we really just need something that exposes NewSession(ctx) fetcher.Fetcher

I'd vote weakly (both weak vote and weakly held position) that that might be premature abstraction. If there's probably only that one shape of config fields in the fetcher component, we might as well admit it, because it'll be more discoverable and easier to autocomplete. But, I don't have strong feelings about this, not having a super complete grasp of how diverse fetcher config might be planned to become.

it ended up being an interface anyway! (due to various other changes happening in go-fetcher) :)

aschmahmann · 2021-04-14T07:05:00Z

resolver/resolver.go

-func NewBasicResolver(ds ipld.DAGService) *Resolver {
+func NewBasicResolver(bs blockservice.BlockService) *Resolver {
+	fc := fetcher.NewFetcherConfig(bs)


We previously took in a DagService here which, on the read end, is being replaced by the Fetcher. Shouldn't we pass in a Fetcher interface of some sort instead of a blockservice which then gets wrapped?

Perhaps it's the same outcome either way, but IIUC part of the "ipld-prime" way here is to be dealing with things on a DAG/node rather than block level which means that the thing we want is something that cares about DAGs rather than blocks.

WDYT about having something like a FetcherSession (or better name) interface that just implements NewSession(context.Context) Fetcher? It might make writing tests simpler and allow us to more easily make changes later (i.e. if we need to extend the input interface to do more than either the structs we're using already support then new functionality and the change is easy, or they don't and the change would have been hard either way).

this all ended up happening!

resolver/resolver.go

aschmahmann · 2021-04-14T07:19:53Z

resolver/resolver.go

-			break
-		}
+	// resolve node before last path segment
+	nodes, lastCid, depth, err := r.resolveNodes(ctx, c, pathSelector)


I'm likely missing something here, but why can't I just use resolveNodes for the full path selector/why do we need to stop and make the last path segment special?

IPLD selectors will follow a link transparently. If we're going to match the current behavior of the function, which returns the CID of the block pointed to by the last segment on the path without loading the block itself, we need to stop the selector traverse before the block gets loaded. If we traverse the full path with a selector, the block will get loaded. Perhaps @warpfork can clarify

Yep, this is like the difference between stat and lstat in linux syscalls. Most of IPLD functions are behaviorally like stat; they'll traverse links implicitly. In particular, yeah, as currently written, traversal.Walk loads links before inspecting them to see if the link node is matched itself.

I'd be open to having more lstat-like functionality in go-ipld-prime. (If someone wants to do that, 👍 But assume that won't make this PR easier to land today, so, 🤷 )

without loading the block itself

To make sure I understand, are you saying the issue is that if rootCID/foo/bar is a CID bafybar then we'll end up loading the block instead of just returning the CID? In the case where rootCID/foo/bar is an integer but rootCID/foo is a CID we'll have to load the rootCID/foo block anyway.

If so @warpfork any thoughts on if this is the way to resolve this? I'd think that basically all of the logic from this function would live in a selector traversal.

@aschmahmann your summary is correct.

In practice, most path in IPFS is protobuf, where each segment really is a whole new node. We're trying to not have any more actual block loads (which are a network fetch) than before, and I believe the code as written mirrors what is current in terms of network fetches.

In the long term, as @warpfork points out, this repository is highly transitional at this point, so there may not be elegant solutions to everything. We are shooting for as much backward compatibility as possible.

resolver/resolver.go

aschmahmann · 2021-04-16T23:10:57Z

resolver/resolver_test.go

+	resolver.FetchConfig.NodeReifier = unixfsnode.Reify
+	node, lnk, err := resolver.ResolvePath(ctx, p)
 	if err != nil {
 		t.Fatal(err)
 	}

+	uNode, ok := node.(unixfsnode.PathedPBNode)


Is UnixFS really required here, aren't we just traversing DagPb nodes?

iiuc this go-path library is really all for unixfsv1 semantics. If we just wanted to traverse over dagpb nodes directly, we'd... traversal.* over ipld.Node, and there'd be nothing here.

I'm hoping in the longer run, this whole library will also just disappear into being a "normal" traversal.* over these things from the unixfsnode package, which are actually ADLs that are making the unixfsv1 semantics legible as normal Node step-wise semantics. IIUC, where were at now, with this PR, is that we're eroding go-path into being becoming this (but not getting rid of go-path yet, because incrementalism/scope-avoidance/you-know).

What this is testing is that the NodeReifier hook system is actually producing one of those ADLs.

Yea what we're trying to do is maintain current behavior -- which is pathing by string, which neccesitated the unixfsnode library.

Even with regular protonodes -- not unixfs files/directories -- you need the ADL to do pathing by string.

resolver/resolver_test.go

aschmahmann · 2021-04-16T23:26:53Z

go.mod

+	github.com/ipfs/go-blockservice v0.1.4
+	github.com/ipfs/go-cid v0.0.7
+	github.com/ipfs/go-datastore v0.4.5
+	github.com/ipfs/go-fetcher v1.2.0
+	github.com/ipfs/go-ipfs-blockstore v0.1.4
+	github.com/ipfs/go-ipfs-exchange-offline v0.0.1
+	github.com/ipfs/go-ipld-cbor v0.0.3
+	github.com/ipfs/go-ipld-format v0.2.0
+	github.com/ipfs/go-log v1.0.4
+	github.com/ipfs/go-merkledag v0.3.2
+	github.com/ipfs/go-unixfsnode v1.1.1
+	github.com/ipld/go-ipld-prime v0.9.1-0.20210402181957-7406578571d1
+	github.com/stretchr/testify v1.7.0


It kind of bothers me that we've ended up with so many extra dependencies here, even though they're mostly just used for testing. I feel like @warpfork may have some thoughts/suggestions here.

Yeah... there's a mixture of things going on here though...

I bet a couple of these are new because the go mod tidy tool is listing more things lately (and they're not actually new dependencies).

Yeah, I'd like this list to be less...

... but testing is a predominatingly worthy cause, if that's what's causing them to appear.

It's maybe not worth spending a ton of time on it in this repo, if we hope to erode this repo into the abyss entirely. (But let's watchdog intensely on the things that replace it, yeah.)

The real problem, no matter which way we slice it, is... if you really wanna be sad, go look at the lock file. Somehow we've got transitive dependencies sprawling all the way to etcd (??) and btcd (?!) and gopherjs (??!). I don't know which of these direct dependencies has those wildly out of control transitive sprawls, but that's probably the thing I'd worry about first.

There a few less now. Some are just new dependencies (the fetcher). A few are yes -- for testing. While we could drop a bunch of these by switching away from protonodes, I'd rather not we ship v0.10.0 with these changes -- the main consume of this functionality is UnixFS, so it feels important to test the main exercised code path.

* first pass * Update resolver/resolver.go Co-authored-by: Eric Myhre <hash@exultant.us> * update dependencies to tagged versions * correctly handles nested nodes within blocks * return link from resolve path so we can fetch container block * return expected NoSuchLink error * more accurate errors * feat(resolver): remove resolve once remove ResolveOnce as it's no longer used and is just confusing Co-authored-by: acruikshank <acruikshank@example.com> Co-authored-by: Eric Myhre <hash@exultant.us> Co-authored-by: hannahhoward <hannah@hannahhoward.net>

…e reifier

resolve go vet and staticcheck issues. note we had to ignore two lines that use deprecated behavior, but which replacing could have unintended effects

hannahhoward · 2021-07-24T00:37:04Z

Note: I had to update go-log cause of dependencies

This module uses EventBegin in logging, and I've for the moment told the linter to ignore the Deprecation warnings, as switching away from EventBegin feels out of scope for this ticket. (also I don't know what we tend to replace it with)

warpfork · 2021-08-04T12:59:25Z

Fairly large comment coming. It will be non-blocking for this PR, but is triggered by my journey trying to understand the PR. You can skip it, unless you're thinking about where we're going with all this in the future.

TOC:

We have a lot of repos
Discovery log
Summary

We have a lot of repos

In reviewing this, I got the feeling I'm implicitly reviewing things across a number of other repos.

And indeed: I drew a graph of go modules that reach between go-ipfs and go-ipld-prime as of today's tip of PR7976, and the current versions any of them reference amongst themselves:

It's pretty hairy.

Some of these (especially some of the sheer versions within each module) should go away by the time we're done with the mergeparty. Some of the complexity will stick around. And some of these repos are new (which frankly terrifies me, by default, unless they're outweighed by the number of repos disappearing).

I want to understand:

which things were legacy, but are already removed by the end of this mergeparty; vs
which things were legacy, but will still stick around at the end of this mergeparty, in a deprecated/transitional state; vs
which things are new but only intended as a transitional state; vs
which things, either new or old, we intend to have stick around.

More things in those middle two states means we've got more work to do in the future, but also means there's a broader range of what we frame as acceptable and successful for the current work cycle.

☁️ ☁️ ☁️ ☁️ ☁️

discovery log

This section is going to be high detail and high noise. Consider skipping it and going straight to the Summary at the end.

The following notes are stream of consciousness.

And I'm going to brain-OOM at least once in the middle of these notes. I'm confessing that very intentionally: I think other people will probably also brain-OOM when trying to chart this, because it's legitimately a maze. We'll need to keep this in mind when allocating time for work (and for planning work!) in the future. If we don't make good roadmaps, and document intended scope for repos... we'll get stuck doing re-discovery like this, and it's both time-consuming, and ultimately reduces the odds of success in reaching a simpler state by the end of renovations. Roadmaps and scope docs are good. Not time-cheap to make. But worth it.

Okay! Here we go:

go-path (this repo) is now depending on go-fetcher.
- This mostly replaces dependencies it previously had on go-ipld-format.DAGService. We consider this a good thing, and a first class goal. (go-ipld-format.DAGService depends on the go-ipld-format.Node interface, which, broadly speaking, we're trying to replace with go-ipld-prime.Node.) Okay. 👍
go-fetcher is a bunch of glue code, and in particular, wraps a blockservice.BlockService from https://github.com/ipfs/go-blockservice into something that can be communicated with using go-ipld-prime.Node.
- (This repo may have had more aspirations than this when created, but I don't know if that remains true. I'm calling what I see.)
- I'm going to assume this accomplishes connecting new code to important parts of existing codebases we still need to plug together. Okay. 👍 But let's recurse into that and try to check that assumption...
Is go-blockservice a temporarily convenient place to shore up the renovation wave, or something we want to continue to route energy through for a long time to come?
- the go-blockservice readme is mostly a TODO mentioning it would be nice if "blockservice" and "blockstore" were more the same thing.
  - I'm going to stop recursing into understanding that right now. I'm starting to think this is some part of the legacy world that we should be trying to continue moving away from in the future, somehow (in large part due to this lack of clarity).
- The one thing I do know is that a lot of existing critical code for actual data-on-disk implements ... wait. "datastore"? Things like go-ds-flatfs implement "datastore"? What's... that? I am now juggling the concepts of "datastore", "blockstore", and "blockservice". How do I get from a "datastore" to a "blockservice"? Are there supposed to be this many layers here? Do the number of layers provide value that's worth their complexity? Are they even layers?
- Brain OOM, stack reset. 😵
- I'm going to assume that someone looked at this, and determined that go-fetcher can get work done by wrapping this blockservice thing, and that has proved sufficient for now, and this at least an acceptable temporary convenient place to shore up any renovation waves. I will assume I currently know nothing else about a timescale on which things below this may be revisited. 🤕 Okay. Stack pop, back up to the top.
  - This makes me struggle to analyze the degree to which go-fetcher should be seen as a permanent, intentional API nexus, or if it's a transitional one, and could be eventually bundled back into some other repo for reduced friction and repo fragmentation.
go-path (this repo) is now depending on go-unixfsnode.
- go-unixfsnode is probably our pride and joy out of this whole raft of changes and repos. We're gathering together all the unixfs and pathing logic there, in one place, and cleaning it up to be an ADL at the same time, which considerably clarifies the logic, standardizes the APIs, etc, and even gets us closer to new features like "selectors over unixfs". Moving things to depend on this is 👍 👍 👍
- So what is go-path left with? It's all facades to minimize change and reduce the amount of refactoring for things downstream of go-path.
go-path is also, still, depending on go-ipld-format. (The thing we're most pointed trying to move off of.)
- Some of go-path's public interfaces are returning things like go-ipld-format.NodeGetter, go-ipld-format.Node, and go-ipld-format.Link (which, n.b., is the struct with things like size fields in it, not just a CID, which is what we usually mean when we say "link" in modern conversations). We can't get rid of these yet because we're trying to minimize change.
Recheck: why are we trying to minimize change here in go-path? Who are the downstreams, and what makes this repo's public APIs a good place to try to hold?
- The two things that depend on go-path that I can see are: go-ipfs and go-mfs.
- If it was just go-ipfs, I'd say: "let's just move this into the go-ipfs repo; it'll make future work have less friction".
- I guess we're probably unwilling to recurse into renovating go-mfs. I have heard it's complex over there for some reason.
- Okay. ✅
Is the go-path/resolver.Resolver type at all sensible anymore?
- Probably not, frankly. Questioned previously in another review.
- But again, apparently the choice made in this PR is that it's sticking around because we're trying to avoid having to change more downstreams today.
Note that currently neither go-unixfsnode depends on go-fetcher, nor vice-versa.
- That seems good and correct. 👍 👍
- go-path is drawing them together.
- If go-path is renovated out of existence in the future, the gluing go-unixfsnode to something that does IO like go-fetcher will have to move... somewhere. That is a decision for down the road. Shouldn't be a problem. 🆒
go-path (this repo) depends on go-merkledag.
- I think we're mostly trying to consider go-merkledag legacy and try to move away from it, too. (It's got icky stuff like weirdly protobuf-specific APIs all over the place, etc.)
- but since go-path as a whole is a transitionary state thing we're going to try to move off of... we won't waste time worrying about it depending on other transitionary-move-away-plz stuff.
Not seen in this repo, but in the neighborhood:
- go-ipfs, interface-go-ipfs-core, and go-mfs all still also depend on go-unixfs (as opposed to go-unixfsnode, which is more modern). This is probably all "future work". Okay. ✅
- go-mfs is referring to a pretty old version tag of go-path? It's probably already tested to be not a problem with the new version, though, because Minimum Version Selection from go-ipfs should've already caused it to be tested together.
  - But it may be worth bumping go-mfs's version references anyway, just to reduce the range of things we have to consider in the future?

☁️ ☁️ ☁️ ☁️ ☁️

summary

Let's answer those original questions by color-coding these repos:

⚫ = legacy, successfully removed by the end of this mergeparty.
🟤 = legacy, but failed to remove yet: will still stick around after the end of this mergeparty, and still considered in a deprecated/transitional state.
🟠 = new but only intended as a transitional state.
🟢 = either new or old, we intend to have stick around.

Green and black are good. Brown and orange mean there's still work to do in future cycles.

Repos:

go-path: 🟤
go-fetcher: 🟠 (... I think? unclear, see fulltext above)
go-unixfsnode: 🟢
go-unixfs: 🟤
go-merkledag: 🟤
go-ipld-format: 🟤
(and there are a couple other new 🟠 too, but not in the reach beneath this repo, so I'll elide them from this post.)
go-ipld-format.DAGService (not at repo scale): ⚫ (yay! got one!)

Okay. Ouch. That's a lot of brown circles. We didn't get a lot of successful removes. That means we're definitely not done renovating. And it also means we didn't score a lot of wins for overall complexity reduction yet (-> we might not actually be scoring dev velocity improvements by the end of this PR & mergeparty, either).

I think we still consider this a good outcome. A lot of work was accomplished. (A lot of it is just at higher granularity than this repo/module-sized field-of-view can easily see.) There's one green circle that's a new thing that we're really happy about, and this PR here in go-path is bringing that into the fold and making it load-bearing. Win. We got a bunch of go-ipld-prime interfaces showing up higher and higher into this dependency graph. Win. Even if we do have a lot of these brown circles, they're increasing becoming facades. Win.

And now we're at the end of a time-box for working on this.

Hopefully we're in a better position for the next round of work. And hopefully in that next round of work, we'll take a bunch more of these brown circles and move them to black.

Sorry for the verbosity. I just really needed to refresh on what the goalposts are. This PR is easier to review (and a lot easier to be happy about!) when one remembers that yeah, a lot of it is gonna smell janky because it's still constrained by legacy -- it's transitional code and we know it -- and the goal isn't to polish this, it's to move on quickly and try to replace most of this with other new APIs that are better, in the next round of work.

Knowing and agreeing that we're not looking for polish / sanitization / complexity-reduction out of this patchset makes it much easier to approve.

warpfork

I think I'm basically good with this.

The reached state is not attractive, but the reasoning about where to park scope for right now seems to hold.

aschmahmann · 2021-07-30T13:51:17Z

go.mod

+	github.com/ipld/go-codec-dagpb v1.2.1-0.20210330082435-8ec6b0fbad18
+	github.com/ipld/go-ipld-prime v0.9.1-0.20210402181957-7406578571d1


TODO: When we're ready to merge let's use tagged versions

yes that is understood.

aschmahmann · 2021-07-30T13:52:17Z

resolver/resolver.go

 // Resolver provides path resolution to IPFS
-// It has a pointer to a DAGService, which is uses to resolve nodes.
+// It reference to a FetcherFactory, which is uses to resolve nodes.


Perhaps "It references a" or "It has a reference to a"

aschmahmann · 2021-08-05T15:48:20Z

resolver/resolver.go

-			break
-		}
+	// resolve node before last path segment
+	nodes, lastCid, depth, err := r.resolveNodes(ctx, c, pathSelector)


without loading the block itself

To make sure I understand, are you saying the issue is that if rootCID/foo/bar is a CID bafybar then we'll end up loading the block instead of just returning the CID? In the case where rootCID/foo/bar is an integer but rootCID/foo is a CID we'll have to load the rootCID/foo block anyway.

If so @warpfork any thoughts on if this is the way to resolve this? I'd think that basically all of the logic from this function would live in a selector traversal.

aschmahmann · 2021-08-05T17:48:58Z

resolver/resolver.go

+	if len(nodes) < 1 {
+		return nil, nil, fmt.Errorf("path %v did not resolve to a node", fpath)
 	}


Is this allowed to not equal 1? Since we're using a pathLeafSelector shouldn't we only match the last element in the path?

I don't see any instance in which it could be greater than 1 based of the way selectors work.

It should equal exactly 1, assuming the entire path was resolved -- if it wasn't, then it will have 0 nodes, indicating a failure.

resolver/resolver.go

aschmahmann · 2021-08-05T17:57:56Z

resolver/resolver.go

 }

 // ResolveSingle simply resolves one hop of a path through a graph with no
 // extra context (does not opaquely resolve through sharded nodes)
-func ResolveSingle(ctx context.Context, ds ipld.NodeGetter, nd ipld.Node, names []string) (*ipld.Link, []string, error) {
+// Deprecated: fetch node as ipld-prime or convert it and then use a selector to traverse through it.
+func ResolveSingle(ctx context.Context, ds format.NodeGetter, nd format.Node, names []string) (*format.Link, []string, error) {
 	return nd.ResolveLink(names)
 }

 // ResolvePathComponents fetches the nodes for each segment of the given path.
 // It uses the first path component as a hash (key) of the first node, then
 // resolves all other components walking the links, with ResolveLinks.


Does the code or the comment here need to change? Why aren't we using ResolveLinks as before, do the functions not quite match up anymore, is it an efficiency thing, etc.?

It should change and I will make said change.

As for why they don't quite operate the same any more... the functions just don't line up in quite the same way and it ends up being easier to seperate them.

resolver/resolver_test.go

aschmahmann · 2021-08-05T18:17:08Z

resolver/resolver_test.go

+	uNode, ok := node.(unixfsnode.PathedPBNode)
+	require.True(t, ok)
+	fd := uNode.FieldData()


Is this correct? randNode() generates a DagPB node that is likely not valid UnixFS.

Should we be checking the "Data" field in the IPLD node instead, or am I missing the point here?

UnixFSNode the repo should probably be renamed something along the lines of "ADLs for DagPB" because it's not entirely just UnixFS.

"PathedPBNode" is an ADL that's not quite UnixFS but also not just DagPB with no additional logic.

Basically, it turns a non-unixfs DagPB node into a map where the keys are the Link names.

We end up needing this for path traversal even when we're not dealing with unixFS.

Perhaps this particular ADL should not live in the go-unixfsnode repo. I don't particularly feel like it's pressing to move it right this second though.

IIUC this is interesting. It seems like we currently (i.e. before the IPLD prime PRs) support pathing through DagPB (not UnixFS) data by name even when ignoring the UnixFS resolver. This also seems to preclude any ability to address by path the Data fields in DagPB nodes or the Size fields in their links.

AFAICT this seems like a mistake since it prevents some of the DagPB data from being addressable by pathing. This is likely something we'll need to resolve as part of ipfs/kubo#7976 (comment).

resolver/resolver_test.go

…fields (#42) * fix(resolver): LookupBySegment to handle list indexes as well as map fields * Add test for /mixed/path/segment/types/1/2/3

hannahhoward · 2021-08-06T05:14:01Z

@warpfork regarding your larger analysis, I largely agree with your conclusions.

I would say the goals of this work were two fold:

Unlock a couple key stakeholder use cases, namely using DAG-JOSE
Learn more about what is needed to fully replace our old ipld libraries in IPFS

I would say overall these two goals have been achieved. With the caveat that I think we learned more about some things than others.

go-unixfsnode, while somewhat inadvertant, turned out to be the most fruitful exploration here, teaching us a lot about what ADLs can do, and how to actually get rid of go-unixfs eventually.

go-fetcher in my mind was originally intended to eventually replace go-merkledag and go-blockservice, but that would require a bunch more work. Moreover, I'm not sure we've proved the interfaces by any means. I suspect the integration with Filecoin will help drive clarity on what our top level "go get me some stuff, either from disk or the internet" interface should ultimately look like. That's why I'm personally happy it did not make it on to the IPFS Core API. I think we learned something but not as much as I'd hoped. As you say, right now it's mostly glue code and utility functions on top of go-ipld-prime & go-blockservice

While we haven't "won" yet in the sense of making the code simpler, ultimately, almost every single node now used in IPFS has an ipld-prime implementation underneath (mostly do, for better or worse, to our go-ipld-legacy shim layer). This was always a part 1 of many, and I really would like to get it merged soon so it's not hanging out there forever.

hannahhoward · 2021-08-06T05:16:29Z

@aschmahmann I've address the various PR comments and I hope we're at the point of approval?

BigLep · 2021-08-10T16:37:43Z

@aschmahmann : is going to leave a comment on some weirdness he sees in the test.

aschmahmann

Left a nit, but otherwise seems good to go here.

aschmahmann suggested changes Apr 16, 2021

View reviewed changes

aschmahmann reviewed Apr 16, 2021

View reviewed changes

acruikshank and others added 7 commits July 22, 2021 11:22

fix(update to tagged branches): update to tagged branches and use nod…

46ece8f

…e reifier

fix(deps): update go-unixfsnode

c9abe36

fix(deps): update to latest go fetcher (#37)

1b4a2c3

feat(resolver): take fetcher config as parameter (#38)

95eac44

fix(deps): switch to tagged go-fetcher

9a213ad

fix(resolver): removed ipldcbor dependency

1fd7492

hannahhoward force-pushed the feat/ipld-in-ipfs branch from 802a897 to 1fd7492 Compare July 22, 2021 18:48

fix(mod): remove unneeded deps

a83b564

hannahhoward mentioned this pull request Jul 22, 2021

IPLD Prime In IPFS: Target Merge Branch ipfs/kubo#7976

Merged

48 tasks

hannahhoward added 3 commits July 23, 2021 09:57

fix(resolver): correct comments

5d6ea22

test(resolver): add test verifying ErrNoLink functionality

a44fc15

fix(lint): fix lint errors

8f5172b

resolve go vet and staticcheck issues. note we had to ignore two lines that use deprecated behavior, but which replacing could have unintended effects

warpfork approved these changes Aug 4, 2021

View reviewed changes

warpfork mentioned this pull request Aug 4, 2021

Use IPLD-prime: target merge branch ipfs/go-merkledag#67

Merged

aschmahmann suggested changes Aug 5, 2021

View reviewed changes

fix(resolver): LookupBySegment to handle list indexes as well as map …

6814a6f

…fields (#42) * fix(resolver): LookupBySegment to handle list indexes as well as map fields * Add test for /mixed/path/segment/types/1/2/3

feat(resolver): address more PR comments

64298be

aschmahmann approved these changes Aug 10, 2021

View reviewed changes

hannahhoward added 3 commits August 11, 2021 08:51

style(tests): add clarification

29c0007

style(lint): fix lint errors, redo test fix

18a10cd

fix(deps): update deps to tagged version

26ca05e

hannahhoward merged commit ea3a116 into master Aug 12, 2021

This was referenced Aug 15, 2021

Fix selector helpers ipfs/go-fetcher#24

Merged

Executing a selector against a DagService ipld/go-ipld-prime#200

Closed

aschmahmann mentioned this pull request Aug 23, 2021

Release v0.10 ipfs/kubo#8176

Closed

62 tasks

aschmahmann mentioned this pull request Sep 15, 2021

fix: give one minute timeouts to function calls instead of block retrievals #44

Merged

		github.com/ipld/go-codec-dagpb v1.2.1-0.20210330082435-8ec6b0fbad18
		github.com/ipld/go-ipld-prime v0.9.1-0.20210402181957-7406578571d1

IPLD Prime In IPFS: Target Merge Branch #36

IPLD Prime In IPFS: Target Merge Branch #36

Conversation

hannahhoward commented Apr 2, 2021

aschmahmann left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

warpfork Aug 3, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

warpfork Apr 19, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hannahhoward commented Jul 24, 2021

warpfork commented Aug 4, 2021 • edited Loading

We have a lot of repos

discovery log

summary

warpfork left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hannahhoward Aug 6, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hannahhoward commented Aug 6, 2021 • edited Loading

hannahhoward commented Aug 6, 2021

BigLep commented Aug 10, 2021

aschmahmann left a comment

Choose a reason for hiding this comment

warpfork Aug 3, 2021 •

edited

Loading

warpfork Apr 19, 2021 •

edited

Loading

warpfork commented Aug 4, 2021 •

edited

Loading

hannahhoward Aug 6, 2021 •

edited

Loading

hannahhoward commented Aug 6, 2021 •

edited

Loading