Re: Async package.el

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Artur,

On 04/06/2015 01:46 PM, Artur Malabarba wrote:
> This is a heads up that I've pushed some commits that implement
> asynchronicity in package.el. I'll explain implementation details below,
> but I want to list the surface changes first.

One change I've noticed recently, is that the last few times I ran `M-x 
list-packages', it didn't display the "new" packages at the top.

Might that be related to the recent changes?

> - For the sake of simplicity, when you hit `x' in the package-menu you
> will no longer get two separate prompts for install/delete. You'll be
> prompted a single time for everything.

I think "INSTALL (xxx-y.z) and DELETE (xxx-z.t)" is needlessly verbose. 
It should probably be "Upgrade (xxx to z.t)", with maybe "and delete the 
currently installed versions".

> - Most functions which involve downloading data now take an extra
> optional ASYNC argument (some of them also take an additional CALLBACK
> argument). This defaults to nil. If it is t, any downloads involved are
> performed asynchronously (and, if appropriate, CALLBACK is called
> afterwards).

Shouldn't there be some new tests?

> - The only really async function (actually a macro) is
> `package--with-work-buffer-async'. All other functions simply propagate
> their ASYNC argument down to this one. If ASYNC nil, it just defers the
> work back to `package--with-work-buffer'.

I have to say that package upgrading being only partially asynchronous 
looks perplexing. You say yes - it starts downloading stuff in the 
background - I can move around in the buffer, then suddenly the 
background process takes over in a synchronous fashion - I can't move 
cursor anymore and just watch some messages in the echo area. The 
Compile-Log only pops up at the end.

While parallel downloading sounds good, maybe the overall interface 
should still be presented in a synchronous fashion.

> - Archives are refreshed all at the same time (which leads to a
> signficant speed boost if you have several archives configured), so
> there's a new variable `package--downloads-in-progress' to keep track of
> which archive downloads are still ongoing. The function
> `package--update-downloads-in-progress' takes care of controling this
> variable and calling a relevant hook when it's all done.

I think this is the main upside of the latest changes, currently.

> - Package downloads are performed in sequence, because it is generally
> not safe to do them in parallel

Why not? Simply downloading in parallel should be safe. Maybe not all at 
once, but 2-4 at a time, especially if they come from different 
archives, would be beneficial.