Cabal: Smartness bypass: using supplied package sets as is

[deepfire]

In some scenarios, it would be extremely helpful to allow Cabal's new-build to operate in a simplified mode, whereby it would be supplied with a GHC package set presumed to be used as-is, and so it would look for a solution within that package set, according to the .cabal-specified constraints.

Using the functionality of new-freeze doesn't quite fit the bill, because it's documented to:

which records all of the versions and flags which that are picked by the solver under the current index and flags

..which seems to necessitate undesired specificity -- all we want to specify is just an input package set, but not the extra details -- basically keeping the freedom to use a wider range of inputs (since we can vary versions and flags) that can be "matched" against the cabal file.

[dcoutts]

whereby it would be supplied with a GHC package set presumed to be used as-is, and so it would look for a solution within that package set, according to the .cabal-specified constraints.

Don't give it any source packages (i.e. hackage) and it will do exactly that. It will run the solver but with only the given installed packages available.

[23Skidoo]

@deepfire Feel free to reopen if you think more should be done here.

[deepfire]

@dcoutts, I think there's a scenario worth a closer look. Let's suppose:

1. I have source packages in the cabal project file, and
2. By a whiff of Nix magic these packages have been made available without Cabal's efforts.

Currently, to disable this Cabal's "smartness" and to make it use the Nix-provided packages, I have to edit the project file and remove these source packages references.

I think it might make sense to add an option to explicitly disable this smartness.

[phadej]

if you have source-package-repository in cabal.project you are explicitly telling cabal-install to use those packages, even they have the same versions as in global db or whatever. In this case, it's not a cabal-install who tries to be too smart!

someone mentioned magic!?

[deepfire]

@phadej, what would you recommend for the use case I described, then?

My proposal is to simply add something like --ignore-package-source-repositories or --ghc-packages-only. That would be very explicit, 100% magic-free, presumably fairly trivial to implement and will also satisfy the use case.

[phadej]

There are two things:

• no VCS deps: you should use separate cabal.project without source-repository-package sections
• no Hackage deps: there should be a way to disable a `package-repository* (i.e. Hackage index), even it's specified globally. I don't remember if this has an issue, but I remember being discussed. cc @hvr

[23Skidoo]

no Hackage deps: there should be a way to disable a `package-repository* (i.e. Hackage index), even it's specified globally

I think that right now you need to delete it from ~/.cabal/config.

[23Skidoo]

...also you can specify a different config file with --config-file.

[deepfire]

no VCS deps: you should use separate cabal.project without source-repository-package sections

@phadej, do you believe it is a superior option to enforce maintenance of two separate project files on the Nix users (as an alternative to having a flag to disable those in some fashion)?

[phadej]

@deepfire, reverse the question: Is there any use case for disabling source-repository-package stanzas other than "more convenient Nix usage".

If there are, than it would be more justified to move complexity into cabal-install. Otherwise, I don't really see a point.

If you package is mainly developed by people using nix, make source-repository-package-less cabal.project a default, and provide with source-repository-package file for others.

(imports in cabal.project.local file would help with that too. IIRC there was issues about that: And that's more general approach!)

[deepfire]

After some off-line discussions, we've finally arrived at the proper formulation of the problem:

We want to use cabal-install to build local packages using the project file _only_ for its definition of local packages.

[phadej]

@deepfire what you mean by "its definition of local packages"?

Package specific stanzas?

package my-package
  ghc-options: -Wall

or/and something else?

[dcoutts]

I think a reasonable approach here is to make it easier to maintain project files that have different alternative configurations but that share much common stuff. So that might involve having conditionals and/or includes in project files.

[deepfire]

@phadej, there is a packages clause that lists relative locations of packages in a project -- as per section 5.1.1 of https://cabal.readthedocs.io/en/latest/nix-local-build.html