Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do bounds in a dependency have to propagate upward to the dependant? #359

Open
andreabedini opened this issue Mar 21, 2023 · 3 comments
Open

Comments

@andreabedini
Copy link

Dear Hackage Trustees,

the title is a mouthful but I am wondering if we have a policy for the following situation:

  • pkg-a (the dependant) depends on pkg-b (the dependency) and on pkg-c <2
  • pkg-b also depends on pkg-c <2

Clearly, in this situation, pkg-a cannot be built with pkg-c==2.

My question is, what if pkg-a builds and works correctly with pkg-c==2 when pkg-b is patched/replaced/revised to work with pkg-c==2? Can we revised pkg-a to allow pkg-c==2?

For those who don't or cannot patch/replace/revise pkg-b, pkg-b constraint on pkg-c will be active and prevent pkg-a from building with pkg-c==2 just as before. But those who have the patched/replaced/revised of pkg-b will be able to use pkg-a the way it is without relaxing more constrinats.

This is basically the situation behind #358. Note that I don't think this is necessarily a IOG specific problem, developers could have been vendoring pkg-b in their projects to patch pkg-b to work with pkg-c==2. In that case it would have been necessary to also add allow-newer: pkg-a:pkg-c. I am wondering whether we think this is necesary or can be avoided.

@endgame
Copy link

endgame commented Mar 21, 2023

I personally expect packages to only claim bounds of things that they actually build with. In your example, if pkg-a depends on pkg-b with patches that don't end up making it to the next pkg-b release, you could be in strife.

This seems much less likely to be a problem if you're only talking about bound revisions, but then it's much easier to just to fix the bounds bottom-up, relying on fixes that are actually present on Hackage.

EDIT: I'm not aware of any specific policy about this.

@andreabedini
Copy link
Author

I personally expect packages to only claim bounds of things that they actually build with. In your example, if pkg-a depends on pkg-b with patches that don't end up making it to the next pkg-b release, you could be in strife.

In the case I am referring to, pkg-a does depend on pkg-c directly. Indeed pkg-a uses pkg-c in a way compatible with both version 1 and 2 while pkg-b uses pkg-c in a way that is only compatible with version 1.

@phadej
Copy link
Member

phadej commented Mar 21, 2023

But those who have the patched/replaced/revised of pkg-b

... can patch pkg-a bounds too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants