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.

Sign up for GitHub

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

Jump to bottom

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
Closed

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

ezyang opened this issue Oct 21, 2016 · 2 comments
Labels
Cabal: file format type: discussion

Comments

@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
@ezyang
Drop version check when resolving package names.
a3d6b2d 
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 mentioned this issue Oct 21, 2016
Merged
ezyang added a commit to ezyang/cabal that referenced this issue Oct 21, 2016
@ezyang
Drop version check when resolving package names.
3a6acbe 
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
Copy link
Member

+1 from me.

ezyang added a commit to ezyang/cabal that referenced this issue Oct 21, 2016
@ezyang
Drop version check when resolving package names.
5871387 
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
@ezyang
Drop version check when resolving package names.
cf6ca4d 
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
Copy link
Contributor

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
@ezyang
Drop version check when resolving package names.
af24cef 
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>
erikd pushed a commit to erikd/cabal that referenced this issue Jan 28, 2017
@ezyang @erikd
Drop version check when resolving package names.
b79a1c7 
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
Assignees
No one assigned
Labels
Cabal: file format type: discussion
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ezyang @23Skidoo @dcoutts