Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ignoring all file collisions in the ghc-wrapper feels like a hack. I'd rather not do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's due to buildEnv propagating the dependencies. Not sure how to turn that off. I'd actually prefer to set allowCollisions here regardless because that is what symlinkJoin does by default.
For instance, compare:
vs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer to treat collisions as an error. Because they usually are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how to avoid the regression then. The two packages given in the revert (cabal-plan & aeson), depend on two different versions of uuid-types:
We could just add
map (lib.getOutput "doc")
to the symlinkJoin, if that seems better.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure how to remedy that issue. My problem with the "simple solution" is this: If different versions of a package exist, then these versions differ in the set of dependencies they link or flags they've been compiled with or something like that. Arguably, those differences may very well manifest in the API and in the generated documentation, so I would assume that those
foobar.haddock
files might differ, too. Ignoring collisions means that we'll just pick a random one and link it into the generated store path. But that doesn't feel right. Thefoobar.haddock
file you'll get should be bundled in some obvious way with the library that it belongs to. This means thatdoc
hierarchy might need$out
baked into its directory name, maybe? Then there would be no more file collisions, because the*.haddock
files would no longer be ambiguous. Does that make sense?