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

Extend `--allow-newer` to limit scope to single packages #2756

Closed
hvr opened this Issue Aug 10, 2015 · 11 comments

Comments

Projects
None yet
5 participants
@hvr
Copy link
Member

hvr commented Aug 10, 2015

When trying to fixup cabal-metadata by empirical trial & error tweaks of inter-package depedencies, it's sometimes useful to lift the upper bound only for a single package rather than for every package, as other packages may rely on automatic cabal flags toggled by version ranges (which --allow-newer sometimes breaks) or we actually want all other constraints to remain intact to keep the solver from picking a bad install-plan that may result if all packages ignore that specific upper bound.

So, I hereby propose to enhance the --allow-never feature to allow to specify which package a constraint relaxation shall apply to. Here's a suggested backward-compatible syntax:

--allow-newer foo:base,lens,bar:time

whose meaning would be

  • drop any upper bound for base specified by package foo,
  • drop any upper bound for lens specified by any package
  • drop any upper bound for time specified by package bar

UPDATE: see https://cabal.readthedocs.io/en/latest/nix-local-build.html#cfg-field-allow-newer for documentation of currently supported syntax for --allow-newer and --allow-older.

@23Skidoo

This comment has been minimized.

Copy link
Member

23Skidoo commented Aug 14, 2015

Not really a solver issue, --allow-newer is implemented as a preliminary step before running the solver.

@ezyang

This comment has been minimized.

Copy link
Contributor

ezyang commented Sep 1, 2016

Is there ever a case where you want the old-style sledgehammer usage? It seems rare, maybe we should discourage it?

@23Skidoo

This comment has been minimized.

Copy link
Member

23Skidoo commented Sep 1, 2016

I don't have anything against.

@hvr

This comment has been minimized.

Copy link
Member

hvr commented Sep 1, 2016

@ezyang are you suggesting a warning to be emitted which informs about the more granular syntax?

@ezyang

This comment has been minimized.

Copy link
Contributor

ezyang commented Sep 2, 2016

No, just a note in the docs. I've put in an admonition against in the new nix-local-build PR.

@lspitzner

This comment has been minimized.

Copy link
Collaborator

lspitzner commented Apr 13, 2018

This is not documented in the user-guide or in the commandline help. What is the syntax to do this via config file? Also, I tried to use this via commandline and get this:

> cabal new-build --allow-newer foo:base
cabal: Internal error in target matching. It should always be possible to find
a syntax that's sufficiently qualified to give an unambiguous match. However
when matching 'foo:base' we found foo:base (unknown-component) which does not
have an unambiguous syntax. The possible syntax and the targets they match are
as follows:
cabal: <<loop>>
> cabal --version
cabal-install version 2.2.0.0
compiled using version 2.2.0.1 of the Cabal library 

@lspitzner lspitzner reopened this Apr 13, 2018

@lspitzner

This comment has been minimized.

Copy link
Collaborator

lspitzner commented Apr 13, 2018

Ah sorry, it is in the users-guide. My bad, I suck at using the search feature.

@lspitzner lspitzner closed this Apr 13, 2018

@23Skidoo

This comment has been minimized.

Copy link
Member

23Skidoo commented Apr 13, 2018

Use --allow-newer=foo:base, otherwise it gets parsed as --allow-newer without arguments (i.e. "ignore all upper bounds everywhere"). We've been considering dropping the no-argument form in favour of --allow-newer=all, though.

@hvr

This comment has been minimized.

Copy link
Member

hvr commented Apr 14, 2018

we really should drop the w/o argument variant, as it's too error-prone and moreover it's a too big of a sledge hammer. If you really want to drop all bounds you should say so explicitly

@tom-bop

This comment has been minimized.

Copy link

tom-bop commented Apr 16, 2018

Re: --allow-newer=all: what if there's a package you depend on named all?

@hvr

This comment has been minimized.

Copy link
Member

hvr commented Sep 29, 2018

@tom-bop ...then the special meaning of all takes preference. Given its special meaning throughout the cabal UI, the package name all is marked a reserved package name on Hackage; so at least on Hackage we won't have to deal with this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment