Problem: Our handling of circular dependencies is incomplete

[clacke]

This issue is a continuation of PR #40, and by mentioning it here I'm making the two an circular dependency of information. Resolve this by reading either you prefer first, and lazily waiting to parse the other. :-)

Reading #40 first probably makes the most sense.

Next steps: First, do (2) automatically instead of special-cased as
in this commit. When we break a circular dependency, don't just mark
the bottom package with circularBuildInputs, also mark the top package
with reverseCircularBuildInputs. When we build that package, we do
what we now special-cased for htdp-lib: remove the
reverseCircularBuildInputs from your config.rktd dependencies, unpack
them all next to you, set them all up with their dependencies
half-installed in the current installation scope.

Now, this will make the top package privileged, and anything
depending on a lower package that directly referenced the top package
will get a half-installed package as a dependency.

The next-next step might be to break the asymmetry by detecting the
full circle, install all the packages in the circle as one derivation,
and then figure out what to do with that. Maybe let each of the
package names be an alias to that package.

Another idea might be to give each package in the circle the chance
to be the privileged package. In practice this means you would have a
number of derivations that are isomorph, each with the same packages
installed in that scope, but each with its own name and with a
slightly differently shaped dependency tree underneath. Not sure if
this is horrible. It does mean some package depending on two packages
in the circle will result in a derivation that has both the
half-installed and the fully-setup package in its config.rktd, and
you are likely to get some whining from raco about that.

[clacke]

Here's my plan now: let the transitive dependencies function return two values:

The first is the current return value -- the transitive dependencies of the called package tree. The second is a dictionary of what cycles we are currently in: #hash([top-package . '("bottom" "depends-on-bottom" "etc")])

Today the bottom package in the cycle has the circular-build-inputs value. When you follow the chain back up, propagate this to every package, until you reach either the circular top, or you detect that you are out of the circle (you don't have the same circular-build-inputs already and the top is not in your breadcrumbs). At each step, trim the dependency that had the circular-build-input. This means in a pure cycle, the top package doesn't depend on anything. This is fine, because when you reach the top, you dump all of the accumulated packages in the reverse-circular-build-inputs, so they will be setup at top build time.

If you come in from the side (your dependency has circular-build-inputs that are not in your breadcrumbs and are not you), remove the dependency and put the top there instead.

Regardless if you discover that you are top or side, remove that cycle from the propagated values.

As every derivation depends directly on all transitive Racket dependencies, those will still be built and we won't have to do anything special about them. But circulars except tops won't be built at all (as nobody depends on them) -- they will just be placeholders to store the src value.

Maybe it would be good cosmetics to name the top something other than just the package that happened to become top, but that's not important right now.

Maybe it would be informative to add the trimmed dependencies to some informative attribute, but that's not important right now.

[clacke]

Closed by #92 , 0ef85df .