Forcing reinstall in package.el

Forcing reinstall in package.el

[Phil Hagelberg]

While doing development of packages using package.el, I often find
myself reinstalling packages using M-x package-install-from-buffer.
However, this is a bit cumbersome because I have to remember to delete
the old version of the package out of my .emacs.d first. It would be
nice for package-install-from-buffer to be able to take a prefix
argument or something that would delete the package before attempting
to install it.

I volunteer to implement this if it's desired.

-Phil

Re: Forcing reinstall in package.el

[Ted Zlatanov]

On Tue, 14 Dec 2010 10:21:28 -0800 Phil Hagelberg <phil@hagelb.org> wrote: 

PH> While doing development of packages using package.el, I often find
PH> myself reinstalling packages using M-x package-install-from-buffer.
PH> However, this is a bit cumbersome because I have to remember to delete
PH> the old version of the package out of my .emacs.d first. It would be
PH> nice for package-install-from-buffer to be able to take a prefix
PH> argument or something that would delete the package before attempting
PH> to install it.

PH> I volunteer to implement this if it's desired.

Asking the user to give a prefix argument puts a burden on them.  Can
`package-install-from-buffer' figure out if it needs to delete the old
package on its own, with maybe a y-or-n prompt at the end?

Ted

Re: Forcing reinstall in package.el

[Phil Hagelberg]

2010/12/14 Ted Zlatanov <tzz@lifelogs.com>:
> On Tue, 14 Dec 2010 10:21:28 -0800 Phil Hagelberg <phil@hagelb.org> wrote:
>
> PH> While doing development of packages using package.el, I often find
> PH> myself reinstalling packages using M-x package-install-from-buffer.
> PH> However, this is a bit cumbersome because I have to remember to delete
> PH> the old version of the package out of my .emacs.d first. It would be
> PH> nice for package-install-from-buffer to be able to take a prefix
> PH> argument or something that would delete the package before attempting
> PH> to install it.
>
> PH> I volunteer to implement this if it's desired.
>
> Asking the user to give a prefix argument puts a burden on them.  Can
> `package-install-from-buffer' figure out if it needs to delete the old
> package on its own, with maybe a y-or-n prompt at the end?

To be honest, I'd prefer it if overwriting were the default behaviour
for all installations, but I hesitated to suggest a wide-sweeping
change like that. =) I agree that overwriting should probably be the
default for package-install-from-buffer especially; confirmation is
unnecessary.

-Phil

Re: Forcing reinstall in package.el

[Ted Zlatanov]

On Tue, 14 Dec 2010 17:27:55 -0800 Phil Hagelberg <phil@hagelb.org> wrote: 

PH> 2010/12/14 Ted Zlatanov <tzz@lifelogs.com>:
>> On Tue, 14 Dec 2010 10:21:28 -0800 Phil Hagelberg <phil@hagelb.org> wrote:
>> 
PH> While doing development of packages using package.el, I often find
PH> myself reinstalling packages using M-x package-install-from-buffer.
PH> However, this is a bit cumbersome because I have to remember to delete
PH> the old version of the package out of my .emacs.d first. It would be
PH> nice for package-install-from-buffer to be able to take a prefix
PH> argument or something that would delete the package before attempting
PH> to install it.
>> 
PH> I volunteer to implement this if it's desired.
>> 
>> Asking the user to give a prefix argument puts a burden on them.  Can
>> `package-install-from-buffer' figure out if it needs to delete the old
>> package on its own, with maybe a y-or-n prompt at the end?

PH> To be honest, I'd prefer it if overwriting were the default behaviour
PH> for all installations, but I hesitated to suggest a wide-sweeping
PH> change like that. =) 

I think that's reasonable, since the user chooses what to upgrade from
the package list.  Chong, Stefan, what do you think?

PH> I agree that overwriting should probably be the default for
PH> package-install-from-buffer especially; confirmation is unnecessary.

Yes, that was the specific use case I had in mind.  But maybe there
should be a message with sit-for 2 seconds so the user can tell
something tragic is about to happen.

Ted

Re: Forcing reinstall in package.el

[Tom Tromey]

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

PH> To be honest, I'd prefer it if overwriting were the default behaviour
PH> for all installations, but I hesitated to suggest a wide-sweeping
PH> change like that. =) 

Ted> I think that's reasonable, since the user chooses what to upgrade from
Ted> the package list.  Chong, Stefan, what do you think?

I think the current behavior is better.
Usually installing something that has the same or lesser version is a
user error.  Only a subset of users will actually want to
force-overwrite a package.

A prefix argument would be ok by me.
Or just a new command.

Tom

Re: Forcing reinstall in package.el

[Ted Zlatanov]

On Wed, 15 Dec 2010 13:06:30 -0700 Tom Tromey <tromey@redhat.com> wrote: 

>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
PH> To be honest, I'd prefer it if overwriting were the default behaviour
PH> for all installations, but I hesitated to suggest a wide-sweeping
PH> change like that. =) 

Ted> I think that's reasonable, since the user chooses what to upgrade from
Ted> the package list.  Chong, Stefan, what do you think?

Tom> I think the current behavior is better.
Tom> Usually installing something that has the same or lesser version is a
Tom> user error.  Only a subset of users will actually want to
Tom> force-overwrite a package.

Tom> A prefix argument would be ok by me.
Tom> Or just a new command.

I thought Phil was talking about an upgrade situation (version is same
or newer), not an unconditional overwrite even if the version is older.
Sorry if I misunderstood.

I don't think it's an error to install the same version.  You could have
modified your local version accidentally, for instance.  In that case it
should maybe warn you, but it's still a good thing to be able to overwrite.

Ted

Re: Forcing reinstall in package.el

[Stefan Monnier]

> I think the current behavior is better.
> Usually installing something that has the same or lesser version is a
> user error.  Only a subset of users will actually want to
> force-overwrite a package.

I mostly agree, but also agree that reinstalling is an important case.
Is there any reason prompting the user is not a good solution?


        Stefan

Re: Forcing reinstall in package.el

[Tom Tromey]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

Tom> I think the current behavior is better.
Tom> Usually installing something that has the same or lesser version is a
Tom> user error.  Only a subset of users will actually want to
Tom> force-overwrite a package.

Stefan> I mostly agree, but also agree that reinstalling is an important case.
Stefan> Is there any reason prompting the user is not a good solution?

As long as the prompt is clear that this is probably not what you meant,
I guess it is ok.

Tom

Re: Forcing reinstall in package.el

[Ted Zlatanov]

On Fri, 17 Dec 2010 07:17:51 -0700 Tom Tromey <tromey@redhat.com> wrote: 

>>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
Tom> I think the current behavior is better.
Tom> Usually installing something that has the same or lesser version is a
Tom> user error.  Only a subset of users will actually want to
Tom> force-overwrite a package.

Stefan> I mostly agree, but also agree that reinstalling is an important case.
Stefan> Is there any reason prompting the user is not a good solution?

Tom> As long as the prompt is clear that this is probably not what you meant,
Tom> I guess it is ok.

How about handling the two cases (same and older version) separately:

"Do you really want to install the same version of %s again? (y/n/Y/N) "

"You have %s version %s installed, are you sure you want the older version %s? (y/n/Y/N) "

...and the user can turn those prompts off with package-expert-noprompts
or something like that.

Ted

Re: Forcing reinstall in package.el

[Tom Tromey]

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

Ted> "You have %s version %s installed, are you sure you want the older version %s? (y/n/Y/N) "

I forgot to mention -- installing older versions can break dependencies.
The package activation code will handle this ok (it will not activate
such packages), but it will probably come as a surprise to the user when
some other package stops working.

Tom

Re: Forcing reinstall in package.el

[Ted Zlatanov]

On Fri, 17 Dec 2010 08:56:10 -0700 Tom Tromey <tromey@redhat.com> wrote: 

>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
Ted> "You have %s version %s installed, are you sure you want the older version %s? (y/n/Y/N) "

Tom> I forgot to mention -- installing older versions can break dependencies.
Tom> The package activation code will handle this ok (it will not activate
Tom> such packages), but it will probably come as a surprise to the user when
Tom> some other package stops working.

Does this mean you're OK with the prompts otherwise?

I think if the user asks to install an older version and forces
package.el to do it, they should be responsible for any breakage.

The prompt is too long already so I don't want to extend it with "...and
this will break installed packages if they depend on the newer
version."  But maybe package.el could show "broken" packages that can't
be activated because of the version mismatch?  Or is that already covered?

Ted

Re: Forcing reinstall in package.el

[Tom Tromey]

Tom> I forgot to mention -- installing older versions can break dependencies.
Tom> The package activation code will handle this ok (it will not activate
Tom> such packages), but it will probably come as a surprise to the user when
Tom> some other package stops working.

Ted> Does this mean you're OK with the prompts otherwise?

Sure.

Ted> I think if the user asks to install an older version and forces
Ted> package.el to do it, they should be responsible for any breakage.

I just think it is friendlier to do the right thing instead of breaking
obscurely, and to make experts take an extra step instead of offering
non-expert users a choice that they are often ill-advised to take.

Ted> The prompt is too long already so I don't want to extend it with "...and
Ted> this will break installed packages if they depend on the newer
Ted> version."  But maybe package.el could show "broken" packages that can't
Ted> be activated because of the version mismatch?  Or is that already covered?

It doesn't show them specially right now, but I think it could.

Tom

Re: Forcing reinstall in package.el

[Phil Hagelberg]

2010/12/15 Ted Zlatanov <tzz@lifelogs.com>:
> I thought Phil was talking about an upgrade situation (version is same
> or newer), not an unconditional overwrite even if the version is older.
> Sorry if I misunderstood.
>
> I don't think it's an error to install the same version.  You could have
> modified your local version accidentally, for instance.  In that case it
> should maybe warn you, but it's still a good thing to be able to overwrite.

Reinstalling the same version is very common for package developers.

I'm only talking about overwriting files. Since different versions
live in different paths, if you choose to install an older/newer
version that hasn't been installed yet, you won't get an overwrite
warning either way, so that question is really orthogonal.

The only question about my proposed change is whether overwriting
already-installed packages should happen automatically or require a
prompt/prefix. I suppose it would be possible to have local changes to
your packages that you want to avoid blowing away, so requiring a
prompt is slightly safer. I will work on a patch that does this unless
there are further objections.

-Phil

Re: Forcing reinstall in package.el

[Ted Zlatanov]

On Wed, 29 Dec 2010 12:08:26 -0800 Phil Hagelberg <phil@hagelb.org> wrote: 

PH> 2010/12/15 Ted Zlatanov <tzz@lifelogs.com>:
>> I thought Phil was talking about an upgrade situation (version is same
>> or newer), not an unconditional overwrite even if the version is older.
>> Sorry if I misunderstood.
>> 
>> I don't think it's an error to install the same version.  You could have
>> modified your local version accidentally, for instance.  In that case it
>> should maybe warn you, but it's still a good thing to be able to overwrite.

PH> Reinstalling the same version is very common for package developers.

PH> I'm only talking about overwriting files. Since different versions
PH> live in different paths, if you choose to install an older/newer
PH> version that hasn't been installed yet, you won't get an overwrite
PH> warning either way, so that question is really orthogonal.

PH> The only question about my proposed change is whether overwriting
PH> already-installed packages should happen automatically or require a
PH> prompt/prefix. I suppose it would be possible to have local changes to
PH> your packages that you want to avoid blowing away, so requiring a
PH> prompt is slightly safer. I will work on a patch that does this unless
PH> there are further objections.

Thanks.  I look forward to testing it :)

Ted

[PATCH] Forcing reinstall in package.el

[Phil Hagelberg]

On Wed, Dec 29, 2010 at 12:08 PM, Phil Hagelberg <phil@hagelb.org> wrote:
> Reinstalling the same version is very common for package developers.
>
> I'm only talking about overwriting files. Since different versions
> live in different paths, if you choose to install an older/newer
> version that hasn't been installed yet, you won't get an overwrite
> warning either way, so that question is really orthogonal.
>
> The only question about my proposed change is whether overwriting
> already-installed packages should happen automatically or require a
> prompt/prefix. I suppose it would be possible to have local changes to
> your packages that you want to avoid blowing away, so requiring a
> prompt is slightly safer. I will work on a patch that does this unless
> there are further objections.

Now I feel silly for not writing this patch sooner since it turned out to be
so simple. So here it is.

2011-02-10  Phil Hagelberg  <phil@hagelb.org>

	* emacs-lisp/package.el (package-unpack-single): Allow packages to
	be reinstalled.


-Phil

From 5f2acffcae9b76aafd1001c8e6bae77d060e29ce Mon Sep 17 00:00:00 2001
From: Phil Hagelberg <technomancy@gmail.com>
Date: Thu, 16 Sep 2010 22:17:59 -0700
Subject: [PATCH] Don't set 'excl when calling write-region.

This fixes a bug where re-installing a package would fail.
---
 lisp/emacs-lisp/package.el |    9 ++++-----
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 54c6a09..3a77cd0 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -574,23 +574,22 @@ Otherwise it uses an external `tar' program.
       (let ((load-path (cons pkg-dir load-path)))
 	(byte-recompile-directory pkg-dir 0 t)))))

-(defun package--write-file-no-coding (file-name excl)
+(defun package--write-file-no-coding (file-name)
   (let ((buffer-file-coding-system 'no-conversion))
-    (write-region (point-min) (point-max) file-name nil nil nil excl)))
+    (write-region (point-min) (point-max) file-name)))

 (defun package-unpack-single (file-name version desc requires)
   "Install the contents of the current buffer as a package."
   ;; Special case "package".
   (if (string= file-name "package")
       (package--write-file-no-coding
-       (expand-file-name (concat file-name ".el") package-user-dir)
-       nil)
+       (expand-file-name (concat file-name ".el") package-user-dir))
     (let* ((pkg-dir  (expand-file-name (concat file-name "-" version)
 				       package-user-dir))
 	   (el-file  (expand-file-name (concat file-name ".el") pkg-dir))
 	   (pkg-file (expand-file-name (concat file-name "-pkg.el") pkg-dir)))
       (make-directory pkg-dir t)
-      (package--write-file-no-coding el-file 'excl)
+      (package--write-file-no-coding el-file)
       (let ((print-level nil)
 	    (print-length nil))
 	(write-region
-- 
1.7.0.4

Re: [PATCH] Forcing reinstall in package.el

[Chong Yidong]

Phil Hagelberg <phil@hagelb.org> writes:

> Now I feel silly for not writing this patch sooner since it turned out
> to be so simple. So here it is.

Thanks.  Committed.