Matthieu Pizenberg

The learning objectives in the design document look good, although as you suggested it might be a lot? I suppose this is pretty far in the curriculum so probably it...

I just had a quick look and didn't find anything shocking with the code. But I don't know much of the context and objectives of the exercise regarding concurrency.

One remark, it’s possible that gleam still depends on pubgrub 0.2.1 as no new version has been published since that. However, a lot has changed on the default `dev` branch....

> a PR to your project do the up graid to the dev branch. whoever does that, it will be a good learning point for improving the upgrade docs. Especially...

Oh I see I think. Basically preloading the resolution with all the root dependencies as incompatibilities. WAIT, isn’t that supposed to be already?

Right, so what we know for sure, at any given time, is the set of incompatibilities inside `internal::core::State` https://github.com/pubgrub-rs/pubgrub/blob/fe65959d72ecff9ad3a555256053d894fa697e57/src/internal/core.rs#L22 As far as I remember, we haven’t yet worked on optimizing...

The only assignments that you can know for sure are those gathered from either the root, or another package where there is no other choice anymore, for example packages picked...

Actually, I had forgotten about it because it was framed as an error message improvements, but Jacob did improve the merging of incompats in https://github.com/pubgrub-rs/pubgrub/pull/163, at least in one case....

The tradeoff seems interesting indeed. The main downside I can see is the maintenance burden that it could create. If more users are encouraged to unroll everything on their own...

Splitting ranges sounds like a good idea to me. Also agree that the `Range` name is not ideal. `Ranges` is slightly better. `Segments` has the same vibe but I prefer...