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

Drop support for depending on non-internal version of package with build-depends constraint #4020

Closed
ezyang opened this Issue Oct 21, 2016 · 2 comments

Comments

Projects
None yet
3 participants
@ezyang
Copy link
Contributor

ezyang commented Oct 21, 2016

Currently in Cabal, you can do this (tested in BuildDeps/InternalLibrary4):

name: p
version: 1.0

library
  ...

executable pexe
  build-depends: p < 1.0

The version constraint on the internal dependency p forces us to use an external copy of p, rather than the internal copy.

This seems like a pretty useless feature. The modular dependency solver is unable to take advantage of this fact. It interacts poorly with --allow-older and --allow-newer. Can we get rid of it?

ezyang added a commit to ezyang/cabal that referenced this issue Oct 21, 2016

Drop version check when resolving package names.
In haskell#4017, hvr reported that when he used --allow-older/--allow-newer,
there was an assert failure in toConfiguredComponent.  Indeed
the problem was that toConfiguredComponent was testing version
ranges of build-depends to determine which package to select, but
there was no satisfying one (since the build-depends field had
not been updated.)

After thinking about this for a bit, it seemed a bit bogus for
us to be doing another version check at this late phase; we
already picked dependencies earlier in the configuration process.
So I decided to drop it.

To drop it, however, I needed to remove support for a feature (discussed
in haskell#4020), which uses version ranges to disambiguate whether or not a
dependency is on an external package or an internal package.  This
feature doesn't seem to be very useful.  If someone asks, I'll
check on Hackage to see if anyone is using it.

Also added some useful extra debug info.

Fixes haskell#4020 and haskell#4017

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Oct 21, 2016

Drop version check when resolving package names.
In haskell#4017, hvr reported that when he used --allow-older/--allow-newer,
there was an assert failure in toConfiguredComponent.  Indeed
the problem was that toConfiguredComponent was testing version
ranges of build-depends to determine which package to select, but
there was no satisfying one (since the build-depends field had
not been updated.)

After thinking about this for a bit, it seemed a bit bogus for
us to be doing another version check at this late phase; we
already picked dependencies earlier in the configuration process.
So I decided to drop it.

To drop it, however, I needed to remove support for a feature (discussed
in haskell#4020), which uses version ranges to disambiguate whether or not a
dependency is on an external package or an internal package.  This
feature doesn't seem to be very useful.  If someone asks, I'll
check on Hackage to see if anyone is using it.

Also added some useful extra debug info.

Fixes haskell#4020 and haskell#4017

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
@23Skidoo

This comment has been minimized.

Copy link
Member

23Skidoo commented Oct 21, 2016

+1 from me.

ezyang added a commit to ezyang/cabal that referenced this issue Oct 21, 2016

Drop version check when resolving package names.
In haskell#4017, hvr reported that when he used --allow-older/--allow-newer,
there was an assert failure in toConfiguredComponent.  Indeed
the problem was that toConfiguredComponent was testing version
ranges of build-depends to determine which package to select, but
there was no satisfying one (since the build-depends field had
not been updated.)

After thinking about this for a bit, it seemed a bit bogus for
us to be doing another version check at this late phase; we
already picked dependencies earlier in the configuration process.
So I decided to drop it.

To drop it, however, I needed to remove support for a feature (discussed
in haskell#4020), which uses version ranges to disambiguate whether or not a
dependency is on an external package or an internal package.  This
feature doesn't seem to be very useful.  If someone asks, I'll
check on Hackage to see if anyone is using it.

Also added some useful extra debug info.

Fixes haskell#4020 and haskell#4017

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

ezyang added a commit to ezyang/cabal that referenced this issue Oct 22, 2016

Drop version check when resolving package names.
In haskell#4017, hvr reported that when he used --allow-older/--allow-newer,
there was an assert failure in toConfiguredComponent.  Indeed
the problem was that toConfiguredComponent was testing version
ranges of build-depends to determine which package to select, but
there was no satisfying one (since the build-depends field had
not been updated.)

After thinking about this for a bit, it seemed a bit bogus for
us to be doing another version check at this late phase; we
already picked dependencies earlier in the configuration process.
So I decided to drop it.

To drop it, however, I needed to remove support for a feature (discussed
in haskell#4020), which uses version ranges to disambiguate whether or not a
dependency is on an external package or an internal package.  This
feature doesn't seem to be very useful.  If someone asks, I'll
check on Hackage to see if anyone is using it.

Also added some useful extra debug info.

Fixes haskell#4020 and haskell#4017

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
@dcoutts

This comment has been minimized.

Copy link
Member

dcoutts commented Oct 22, 2016

Yes. Seems like a feature that must be very rarely used, since it cannot work with any automation (cabal-install or stack).

ezyang added a commit to ezyang/cabal that referenced this issue Oct 25, 2016

Drop version check when resolving package names.
In haskell#4017, hvr reported that when he used --allow-older/--allow-newer,
there was an assert failure in toConfiguredComponent.  Indeed
the problem was that toConfiguredComponent was testing version
ranges of build-depends to determine which package to select, but
there was no satisfying one (since the build-depends field had
not been updated.)

After thinking about this for a bit, it seemed a bit bogus for
us to be doing another version check at this late phase; we
already picked dependencies earlier in the configuration process.
So I decided to drop it.

To drop it, however, I needed to remove support for a feature (discussed
in haskell#4020), which uses version ranges to disambiguate whether or not a
dependency is on an external package or an internal package.  This
feature doesn't seem to be very useful.  If someone asks, I'll
check on Hackage to see if anyone is using it.

Also added some useful extra debug info.

Fixes haskell#4020 and haskell#4017

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

@ezyang ezyang closed this in #4021 Oct 26, 2016

erikd added a commit to erikd/cabal that referenced this issue Jan 28, 2017

Drop version check when resolving package names.
In haskell#4017, hvr reported that when he used --allow-older/--allow-newer,
there was an assert failure in toConfiguredComponent.  Indeed
the problem was that toConfiguredComponent was testing version
ranges of build-depends to determine which package to select, but
there was no satisfying one (since the build-depends field had
not been updated.)

After thinking about this for a bit, it seemed a bit bogus for
us to be doing another version check at this late phase; we
already picked dependencies earlier in the configuration process.
So I decided to drop it.

To drop it, however, I needed to remove support for a feature (discussed
in haskell#4020), which uses version ranges to disambiguate whether or not a
dependency is on an external package or an internal package.  This
feature doesn't seem to be very useful.  If someone asks, I'll
check on Hackage to see if anyone is using it.

Also added some useful extra debug info.

Fixes haskell#4020 and haskell#4017

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment