`shellFor` does not include dependencies of intermediary packages

[michaelpj]

Consider the following:

• A is a project package
  • A depends on B
• B is a Hackage package
  • B depends on C and D
• C is a Hackage package, which has been overridden locally with source-repository-package
• D is another Hackage package

Now, here's what I think happens:

• We realise that A and C are local packages, so their dependencies need to be in the shell
• We filter out B (?) since it's going to be rebuilt anyway
• So we populate the shell with the dependencies of A and C, minus B

But in fact after rebuilding C, cabal will want to rebuild B also, but B is missing one of its dependencies: D!

This doesn't matter if you don't set exactDeps=true, since cabal will just happily build D for you. But if you do, it will complain that it can't find it.

This sounds like exactly the concern that was raised by @hamishmack here: #1146 (comment)

@TeofilC do you remember whether your final version addressed this?

[TeofilC]

I just took a brief glance at that code again, and I think it should handle cases like this.

I think the following would happen in your example.

• We start out with A and C as directly selected packages (directlySelectedComponents).
• We take the transitive closure of their dependencies, which is all of the packages (transitiveDependenciesComponents).
• We compute the set of packages that aren't directly selected but will be built in the shell (selectedComponents). The test for this is that they depend on something that is in selectedComponents. B satisfies this because it depends on C.
• Then the dependencies of the shell are the dependencies of selectedComponents minus selectedComponents. So, that would be C and D.

One thing is that we use selectLocalPackages to get the inital packages. I can never remember the difference between local and project packages. Maybe we want to use the other one?

[michaelpj]

Apologies, this may be a false alarm! There was something else going on with my (apparent) reproducer, I'll look at it more.

[TeofilC]

No worries better to be safe than sorry. Let me know if you figure out the reproducer -- I'd be happy to help fix this

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.