Re: Async package.el

[Dmitry Gutov]

On 04/06/2015 05:32 PM, Artur Malabarba wrote:

> Yes. I'm fixing it now.

Thank you.

> I agree.

I'd also prefer to revert to use the sentence case (non-caps).

b6610d55470c7e835472a581977ab6fad537c8b6 did that change, despite having 
the word "refactor" in its message. :P

> Yes. I'm still trying to figure out how to do async tests. Currently all
> package.el tests use a local directory as the repository, but the async
> functions only kick-in for remote repositories.
> Should I use GNU Elpa for the tests? Might that cause hydra to
> unexpectedly complain due to random connection issues?

I think ideally you'd run a small package archive server locally, 
launched with a tiny Python script.

> I agree that's annoying and I have some similar plans. We can change the
> package-installation logic to first download all files simultaneously,
> and then unpack/compile all of them in the proper order. So large
> upgrades would have a significant speed improvement.

Right, that should be optimal, but the requires changes are probably 
non-trivial.

To take this further (and forgive the negativity), maybe we should 
back-pedal on adding the asynchronous interface to downloading package 
archives, too. While doing it in parallel is great, refreshing the table 
of packages right under the user's nose is bound to create problems. 
Here's one:

M-x list-packages, press `i' in the displayed list, wait for the refresh 
to be done, see the `I' disappear.

Can you imagine something like Ubuntu Software Center doing this and 
updating the packages list while the user's interacting with the 
interface? Aside from it being confusing, the more interface elements 
there are, the higher are the odds of this kind of update breaking 
something.

While `list-packages' is far from complexity of analogous tools, maybe 
we should walk in that direction without having to support the 
complexity of asynchronously updating the packages list.

The slowness of `list-packages' launch could be tackled in different 
ways. We want to have up-to-date information, but we don't have to:

- Update it each time `M-x list-packages' is run. Doing it only once a 
day, by default, should be sufficient for most uses. GNU ELPA is updated 
less often than that anyway.

- Wait until the user invokes `M-x list-packages' to update it. We could 
do it while Emacs is idle. Of course, we user might end up not doing 
anything the packages in the current session anyway, so it'll require 
some experimenting. Maybe check that `M-x list-packages' was called at 
least once since the idle update, and, conversely, still perform the 
synchronous update at the beginning of `list-packages' if the archives 
haven't been updated for a while.

Both approaches should also lower the packages archives' server load, at 
the cost of being slightly less up-to-date.