[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Async package.el

From: Dmitry Gutov
Subject: Re: Async package.el
Date: Tue, 07 Apr 2015 04:19:30 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]