don't constrain cyclic deps to build version

[jhheider]

requires #406 to pass checks

fixes #412

Basically if a dep requests the target (go.dev requires go.dev: '*'), this will prevent locked loop (build go.dev=1.20.1 trying to install go.dev=1.20.1)

[what-the-diff]

• If the dependency is already in the graph, update its constraint to match that of
  this node. This ensures we don't end up with a situation where two nodes have different
  constraints for their dependencies (which can happen if one was installed from lockfile).

[jhheider]

should also allow us to build specific llvm versions.

[mxcl]

seems like you need to implement Range.eq, surely === will only work here if the object itself is the same object?

[jhheider]

This seems to do exactly what I want, in testing. Replaces the build pkg with the dep so we don't require the version we want to build.

[mxcl]

But it's a coincidence that === works. It would be trivial for some part of the code to create a new copy of the object at some prior step.

[mxcl]

k, so changing this code is dangerous. We better get it right.

Can you highlight what part of the code is failing per your failure spec?

[jhheider]

Can you highlight what part of the code is failing per your failure spec?

No patch:

$ ./libexec/deps.ts go.dev~1.20 --build
go.dev must be bootstrapped to build go.dev
curl.se/ca-certs
gnu.org/m4^1
tea.xyz/gx/cc^0.1
openssl.org^1
go.dev~1.20

Patched:

$ ./libexec/deps.ts go.dev~1.20 --build
go.dev must be bootstrapped to build go.dev
curl.se/ca-certs
gnu.org/m4^1
tea.xyz/gx/cc^0.1
openssl.org^1
go.dev

go.dev requires go.dev: '*' to build. But it shouldn't require the explicit version being built (that's madness). Same for llvm.org on linux, iirc. Likely the others that are self-requiring.

[mxcl]

I think the actual solution for the this is to hydrate the deps of go rather than go itself.

So this is a regression in brewkit.

[jhheider]

I think the actual solution for the this is to hydrate the deps of go rather than go itself.

So this is a regression in brewkit.

That sounds like the right answer. However, if you pass two packages and one depends on the other, it won't be "self-hydrating" via the other build. But that might be ok. We generally don't do multi-package builds (and source matching is currently broken due to re-ordering).