"active-repositories: none" reportedly broken

[gbaz]

It is reported on #8944 that this broke active-repositories: none. If so, that's very bad and we should fix it!

[ulysses4ever]

I understand MercuryTechnologies@ec242b1 fixes the problem. Should we cherry pick it?

[gbaz]

Note that this issue occurs only if there is no exising ~/.cache/cabal/packages/hackage.haskell.org -- making this less severe, because it happens on a system where no cabal update has ever been run. Once it has, then the active-repositories flag works as intended...

[geekosaur]

But that gets us back to the question of why it even matters if active-repositories: none?

[gbaz]

Indeed, the error occurs with or without active-repositories passed. Its simply that with active-repositories passed, we might hope it would disable the error.

what appears to be happening is we don't take into account active-repos when reading and validating the repo-index state.

rather, we always fetch from all the available repos. active-repos says, out of all the repos, which are "active" for solving our package set.

i'm much less certain about how bad this behavior is now, and also less certain how far we might want to go to fix it. that said, one solution would be to just turn this one specific error back into a warnning, as it is a different error than the bad index state error. rather, it reads: The package list for 'hackage.haskell.org' does not exist. Run 'cabal update' to download it.

The reason I'm ok with this being turned into a warning is if the user needed that package list to proceed (i.e. for the solver), then subsequent steps would fail anyway -- so all we've done is make the failure mode slightly faster at hte cost of making it overly general.

[gbaz]

Hrm, in fact, that's what the proposed patch PR does. It still throws in every other case -- only in the doesNotExist case does it throw MissingPackageList either as a warning or exception. So now I've come around to seeing this as the correct fix, nice.

[pwm]

It would be great to turn those errors back to warnings.

Also, if active-repositories: none is not the correct flag to instruct Cabal "don't manage my packages", then which, if any flag, is? The comment above active-repositories: none in the official docs says "Offline mode", which I always understood to be that. If we must run cabal update then, afaict, it's not offline mode.

[geekosaur]

We may have a definition problem, which that comment exacedrbates: cabal has an offline mode, but it disables all network access, it doesn't do anything to what repositories are available or how cabal uses them. (Meaning, you must update your repositories and download any dependencies before going offline, which is what most things mean by offline mode.)

[ulysses4ever]

cabal actually has --offline flag, although it has its own limitations.

[pwm]

Then, if I understand it correctly, maybe Cabal is missing a flag to state "build with the packages I provide"? It is a fairly common use case where you want to use Cabal for building but not for package management. Historically, this is what I (mis?)used active-repositories: none for, but maybe it needs its own flag with clear semantics?

[jasagredo]

Ah I was not following the discussion in this thread. So I see that the desired use case is to be able to tell cabal to not use any indices, which in turn means something like an offline mode. At the moment the offline mode seems to mean "do not do network interaction" but it doesn't imply "do not look at the indices", it will actually look at the local copies of the indices when building the plan.

On the other hand, cabal seems to need to read the local indices even when active-repositories: none as that option means "once you are constructing a build plan, do not consider any repositories", but there is more stuff happening before that.

Therefore my proposal would be to add a flag --indexless or --no-indices to go one step beyond and both:

• Disable networking, i.e. no new packages will be downloaded from repositories (achieved already by either of the flags above)
• Ignore the local copies of the repositories, therefore not reading the indices.

This effectively will make cabal just a tool to orchestrate which options to pass to GHC where, and how to build the current package, leaving aside the package-management functionality. Seems reasonable to me.

Another option would be to name the flag --disable-package-management/--no-package-management.

[ulysses4ever]

Let's not close it right away.