Async Package.el Feedback

Async Package.el Feedback

[raman]

Async  behavior for package is a welcome arrival,  here is some hopefully useful feedback on  making things better -- especially when upgrading a large number of packages at one shot.


0. On startup, Emacs still appears to block while  loading the gpg bits for the various archives.

1. Even though installs happen asynchronously, there is a large amount of chatter in the Messages area -- can that be silenced?

2. This is a admittedly a special case: For many years, my emacs-startup file is called emacs-startup.el and is versioned by git -- ~!/.emacs is a symlink.

The code in package.el that adds the (package-initialize) to the top  of the startup file appears to go open the startup file each  time to  check if its magic cookie is present at the top -- so in my case, each package update caused the yes/no prompt -- perhaps remember that the cookie is added via a lisp var (hopefully customizable by the user) 
-- 

-- 

-- 

Re: Async Package.el Feedback

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

> 0. On startup, Emacs still appears to block while  loading the gpg bits
for the various archives.
>
> 1. Even though installs happen asynchronously, there is a large amount of
chatter in the Messages area -- can that be silenced?

Thanks for the comments, I'll look into improving these points

> 2. This is a admittedly a special case: For many years, my emacs-startup
file is called emacs-startup.el and is versioned by git -- ~!/.emacs is a
symlink.
>
> The code in package.el that adds the (package-initialize) to the top  of
the startup file appears to go open the startup file each  time to  check
if its magic cookie is present at the top -- so in my case, each package
update caused the yes/no prompt -- perhaps remember that the cookie is
added via a lisp var (hopefully customizable by the user)

Technically this is unrelated to the async feature, but it looks like a
serious issue. What yes/no prompt are you talking about?

[-- Attachment #2: Type: text/html, Size: 1082 bytes --]

Re: Async Package.el Feedback

[raman]

The yes/no prompt I am talking about:

In general in emacs, if you attempt to edit a file through its symlink
you get a yes/no prompt saying "Follow symlink?" or some such.

In the case of package.el -- when I updated 28 packages, I got that
prompt 28 times.
-- 

Re: Async Package.el Feedback

[Artur Malabarba]

Oh, that's pretty bad. I've never seen this prompt before. I'll try to
write up a solution.

2015-04-07 16:23 GMT+01:00 raman <raman@google.com>:
> The yes/no prompt I am talking about:
>
> In general in emacs, if you attempt to edit a file through its symlink
> you get a yes/no prompt saying "Follow symlink?" or some such.
>
> In the case of package.el -- when I updated 28 packages, I got that
> prompt 28 times.
> --

Re: Async Package.el Feedback

[Rasmus]

raman <raman@google.com> writes:

> The yes/no prompt I am talking about:
>
> In general in emacs, if you attempt to edit a file through its symlink
> you get a yes/no prompt saying "Follow symlink?" or some such.
>
> In the case of package.el -- when I updated 28 packages, I got that
> prompt 28 times.

I cannot reproduce for a general symlink from emacs -q, but I can
reproduce for a file linking to a git-controlled file.  To avoid the
prompt I set vc-follow-symlinks to non-nil.

    vc-follow-symlinks is a variable defined in `vc-hooks.el'.
    Its value is t
    Original value was ask

    Documentation:
    What to do if visiting a symbolic link to a file under version control.
    Editing such a file through the link bypasses the version control system,
    which is dangerous and probably not what you want.

    If this variable is t, VC follows the link and visits the real file,
    telling you about it in the echo area.  If it is `ask', VC asks for
    confirmation whether it should follow the link.  If nil, the link is
    visited and a warning displayed.

—Rasmus

-- 
Send from my Emacs

Re: Async Package.el Feedback

[T.V Raman]

Simple way to repro: create symlink foo to file bar, then find-file
foo you'll see the dialog/prompt I'm talking about.
-- 

-- 

Re: Async Package.el Feedback

[Artur Malabarba]

I just did the following and I don't get any prompt.

    ln -s file1 file2
    emacs -q
    M-x find-file file2

But if `file1' is a version controled file, then I do get the prompt
(asRasmus explained).

I think I'll do 2 things about this:

1. Read the contents of the file before visiting it, so if it already
contains `package-initialize' we don't need to visit it at all. This
will get rid of this prompt for users who version control their init
file.
2. Do this visiting thing during package-initialize instead of during
package-install, this way it should only happen once per session
(unless the user manually initializes again, which is not a big
issue). This way, if another unexpected corner case like this shows
up, the user won't get faced with the problem 28 times in a row.


Another possibility I've been considering would be to let go of this
solution and switch to the second solution initially proposed on the
other thread (checking a file or an enviroment variable to decide
whether to package-initialize at startup or not).

2015-04-07 17:28 GMT+01:00 T.V Raman <raman@google.com>:
> Simple way to repro: create symlink foo to file bar, then find-file
> foo you'll see the dialog/prompt I'm talking about.
> --
>
> --

Re: Async Package.el Feedback

[T.V Raman]

For now, the first solution sounds good to me -- personally
I've always found env vars a source of surprize and prefer to keep
emacs customizations inside emacs. What I do wish for (separate from
package.el) is the ability to 

1. Have the custom file split into a per-package collection of files 

and 
2. A solution that encrypts them all.

The present giant custom file gets very fragile -- I keep losing
settings inexplicably, and encryption would be nice.



Artur Malabarba writes:
 > I just did the following and I don't get any prompt.
 > 
 >     ln -s file1 file2
 >     emacs -q
 >     M-x find-file file2
 > 
 > But if `file1' is a version controled file, then I do get the prompt
 > (asRasmus explained).
 > 
 > I think I'll do 2 things about this:
 > 
 > 1. Read the contents of the file before visiting it, so if it already
 > contains `package-initialize' we don't need to visit it at all. This
 > will get rid of this prompt for users who version control their init
 > file.
 > 2. Do this visiting thing during package-initialize instead of during
 > package-install, this way it should only happen once per session
 > (unless the user manually initializes again, which is not a big
 > issue). This way, if another unexpected corner case like this shows
 > up, the user won't get faced with the problem 28 times in a row.
 > 
 > 
 > Another possibility I've been considering would be to let go of this
 > solution and switch to the second solution initially proposed on the
 > other thread (checking a file or an enviroment variable to decide
 > whether to package-initialize at startup or not).
 > 
 > 2015-04-07 17:28 GMT+01:00 T.V Raman <raman@google.com>:
 > > Simple way to repro: create symlink foo to file bar, then find-file
 > > foo you'll see the dialog/prompt I'm talking about.
 > > --
 > >
 > > --

-- 

-- 

Re: Async Package.el Feedback

[Artur Malabarba]

> For now, the first solution sounds good to me -- personally
> I've always found env vars a source of surprize and prefer to keep
> emacs customizations inside emacs. What I do wish for (separate from
> package.el) is the ability to
>
> 1. Have the custom file split into a per-package collection of files

(Off topic but...) This is technically possible. Instead of packages,
it would make more sense for the customizations to be grouped by group
(as in defgroup). All the necessary information for that is there
already if you want to give it a try. It'll probably be quite a bit of
work.