cabal update (was Re: Delay between hackage upload and cabal-install seeing package)

[Duncan Coutts]

On Fri, 2009-05-15 at 15:23 +0100, Malcolm Wallace wrote:
> > > Personally, I would prefer "cabal install" to automatically refresh
> > > its own local cache (when appropriate), without this extra step.  If
> > > cabal is going to reach out over the net to download package
> > > sources, it might as well ensure that it collects the latest version
> > > of the index first.
> > 
> > The difficulty with this is that we use cabal install for thing we
> > expect to be local.
> > We also support offline operations, we have cabal fetch for just this
> > reason.
> 
> Yes, I think it is important that cabal install can be used off-line.
> Probably the design should be thus:
> 
>   * construct a build plan using local cache
>   * decide whether network downloads are required
>   * if not, proceed with plan and local resources
>   * if yes, then download new index, re-do the plan, and proceed.
> 
> I don't know how soon during the construction of the build plan cabal
> can detect that downloads are required, i.e. only after the full plan is
> constructed, or as soon as any non-local package is mentioned.  However,
> in any case, surely the planning phase is not so computationally
> expensive that it doing it twice would give a noticeable delay?

Probably not noticable. Getting the index however is quite noticable.
It's currently getting rather large (much bigger than most packages). I
think we'd want to implement a scheme to trickle updates before we start
to grab updates more frequently/implicitly.

> > The other thing is that sometimes you don't want the package database
> > to be silently updated. You want to stick with a particular snapshot.
> > It's important that network access be fairly clear to users.
> 
> If users want to stick with a snapshot index, that could be a cmdline
> option, e.g. cabal install --not-latest (or --no-update?).  I do think
> that the current behaviour is occasionally less than transparent to
> users, and a sensible default would be to auto-update.

Yes, the first thing to do would be to add a mode switch that says if
the user wants offline or online behaviour. Then we can think about
which circumstances the default should be one or the other and let user
override it when they want the non-default.

Duncan