search

haskell / cabal

Official upstream development repository for Cabal and cabal-install
https://haskell.org/cabal
Other
1.63k stars 696 forks source link

"active-repositories: none" reportedly broken #10504

Open gbaz opened 3 weeks ago

gbaz commented 3 weeks ago

It is reported on https://github.com/haskell/cabal/pull/8944 that this broke active-repositories: none. If so, that's very bad and we should fix it!

ulysses4ever commented 3 weeks ago

I understand https://github.com/MercuryTechnologies/cabal/commit/ec242b1cb21e450d5212efd5c445f0d70786092e fixes the problem. Should we cherry pick it?

gbaz commented 3 weeks ago

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 commented 3 weeks ago

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

gbaz commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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

pwm commented 3 weeks ago

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 commented 2 weeks ago

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:

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 commented 2 weeks ago

Let's not close it right away.