fix: fix install dependency tracking

[dhellmann]

While working on #695, I noticed that the bootstrapper was changing the dependency type for installation dependencies of build dependencies. That led to invalid graphs, showing for example that torch had no installation dependencies because it was a build dependency of vllm.

Fix that error, and improve logging to show the dependencies discovered and where processing is starting.

[tiran]

This change reverts my commit f61f142 from 5 months ago. I vaguely remember that the commit addressed a bug, but I cannot recall any details.

Perhaps we need to mark the installation requirements of a build requirement as both install requirement and build-system requirement?

[dhellmann]

This change reverts my commit ref61f142668b4279263b25c4775de9b053a099b03 from 5 months ago. I vaguely remember that the commit addressed a bug, but I cannot recall any details.

That reference isn't working for me, but f61f142 does.

Perhaps we need to mark the installation requirements of a build requirement as both install requirement and build-system requirement?

I do remember that, but don't remember the origin, either. Was there an actual behavior problem, or did it just look like the data was wrong?

Without this change the graph file produced for vllm is incorrect. Torch is both a build dependency and an installation dependency, but since it's treated as a build dependency first every installation dependency of torch shows up as a build dependency and is left out of the install set. That means we can't show the proper install set in a graph visualization, but it also means they are being ignored when we produce the constraints file, which is worse.

When we produce the installation set from a graph, we start at the top-level and traverse all edges that have type "install", so I think we're already treating everything correctly in that point.

[tiran]

I think it's related to sdist-only mode. I'm not near a computer to verify the hypothesis right now. In sdist-only mode, Fromager does not build wheels unless the package is flagged as build dependency.

[dhellmann]

I think it's related to sdist-only mode. I'm not near a computer to verify the hypothesis right now. In sdist-only mode, Fromager does not build wheels unless the package is flagged as build dependency.

OK, that makes sense. I think we should separate that logic from what we store in the graph. We can look through the current "why" list to see if anything there is a build dependency instead of using only the current edge's type. I'll make that update next week.

[dhellmann]

I think it's related to sdist-only mode. I'm not near a computer to verify the hypothesis right now. In sdist-only mode, Fromager does not build wheels unless the package is flagged as build dependency.

OK, that makes sense. I think we should separate that logic from what we store in the graph. We can look through the current "why" list to see if anything there is a build dependency instead of using only the current edge's type. I'll make that update next week.

I've updated this PR with a new method on the bootstrapper to figure out whether the current context relates to a build dependency. I think I have the logic right, but we may need some more complex test cases to be sure. Let me know what you think, @tiran

[tiran]

Oh, that's a clever approach. I haven't thought of looking through the why list. I like it.

I have one question.

[rd4398]

Overall looks good
I will leave it to @tiran to approve since he suggested changes