Option to not automatically customize-save-variable `package-selected-packages'?

Option to not automatically customize-save-variable `package-selected-packages'?

[alex]

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

Hello, the 25.0.91 pretest version seems great so far. I like the dependency tracking in package.el.

Unfortunately whenever I install/update packages, it saves `package-selected-packages' to my customize file. This is a bit annoying as I share my config with git across multiple machines that have different packages installed.

While I could alter the definition of `package--save-selected-packages' myself, I'd think it would be nicer if there was a user option to toggle this behaviour. The default initialization of `all non-dependencies' seems to be what I'd always want anyway.

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

Re: Option to not automatically customize-save-variable `package-selected-packages'?

[John Wiegley]

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

>>>>> alex  <current@protonmail.com> writes:

> Hello, the 25.0.91 pretest version seems great so far. I like the dependency
> tracking in package.el.

> Unfortunately whenever I install/update packages, it saves
> `package-selected-packages' to my customize file. This is a bit annoying as I
> share my config with git across multiple machines that have different packages
> installed.

> While I could alter the definition of `package--save-selected-packages'
> myself, I'd think it would be nicer if there was a user option to toggle
> this behaviour. The default initialization of `all non-dependencies' seems
> to be what I'd always want anyway.

This sounds like a reasonable request to me; and I sympathize with emitting
such generated data to a potentially user-controlled file. Maybe this data
could go into another file entirely?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Angelo Graziosi]

John Wiegley wrote:
> This sounds like a reasonable request to me; and I sympathize with emitting
> such generated data to a potentially user-controlled file.

In my opinion this should be matter of principle: Why an application 
should, more o less silently, change the configuration file which 
belongs to the user?

If really the application needs some change in configuration file, this 
should be flagged as an error so that the user takes the appropriate steps..

Since this was added to Emacs, I have a backup copy of my original init 
file so that I can remove those not requested addictions.. and this is 
very annoying...

  Angelo

Re: Option to not automatically customize-save-variable `package-selected-packages'?

[Artur Malabarba]

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

Yes, I agree. This has been requested by other people too. This variable
should be saved in its own file (at a configurable location), like many
other cases of persistent data in Emacs.

Would someone like to do this? I won't have the time for it ATM.

On 17 Feb 2016 2:10 am, "John Wiegley" <jwiegley@gmail.com> wrote:
>
> >>>>> alex  <current@protonmail.com> writes:
>
> > Hello, the 25.0.91 pretest version seems great so far. I like the
dependency
> > tracking in package.el.
>
> > Unfortunately whenever I install/update packages, it saves
> > `package-selected-packages' to my customize file. This is a bit
annoying as I
> > share my config with git across multiple machines that have different
packages
> > installed.
>
> > While I could alter the definition of `package--save-selected-packages'
> > myself, I'd think it would be nicer if there was a user option to toggle
> > this behaviour. The default initialization of `all non-dependencies'
seems
> > to be what I'd always want anyway.
>
> This sounds like a reasonable request to me; and I sympathize with
emitting
> such generated data to a potentially user-controlled file. Maybe this data
> could go into another file entirely?
>
> --
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

Re: Option to not automatically customize-save-variable `package-selected-packages'?

[Colin Baxter]

> Hello, the 25.0.91 pretest version seems great so far. I like the
> dependency tracking in package.el.
>
> Unfortunately whenever I install/update packages, it saves
> `package-selected-packages' to my customize file. This is a bit
> annoying as I share my config with git across multiple machines that
> have different packages installed.
>
> While I could alter the definition of
> `package--save-selected-packages' myself, I'd think it would be nicer
> if there was a user option to toggle this behaviour. The default
> initialization of `all non-dependencies' seems to be what I'd always
> want anyway.

For what's it worth, I found the default annoying in the extreme. At the
very least, the user should be left in no doubt that his init file has
been changed.

C. Baxter.

Re: Option to not automatically customize-save-variable `package-selected-packages'?

[Joost Kremers]

On Wed, Feb 17 2016, John Wiegley <jwiegley@gmail.com> wrote:
> This sounds like a reasonable request to me; and I sympathize with emitting
> such generated data to a potentially user-controlled file. Maybe this data
> could go into another file entirely?

I vaguely remember reading somewhere that `custom-set-variables' /
`customize-save-variable' should not be used to store data that should
persist across sessions, though I can't find right now where I read it.

Of course it can be argued that the user asks for the packages to be
installed and that this fact justifies saving the info to the init file.
At the very least, though, I think there should be an option *not* to do
this. After all, this option exists with customisable variables in
general: the user can decide to use Customize, or s/he can decide to set
variables directly in the init file.

IMHO the location where the list of packages is saved should be
customisable, with the default being something other than the init file
(though that should probably be an option), and with the option not to
save them at all. (I don't use the same set of packages on all machines,
because some packages can be fairly resource-intensive and bog down
Emacs on a lower-spec'ed machine such as my ageing netbook or my phone.)


-- 
Joost Kremers
Life has its moments

Re: Option to not automatically customize-save-variable `package-selected-packages'

[John Wiegley]

>>>>> Angelo Graziosi <angelo.graziosi@alice.it> writes:

> Since this was added to Emacs, I have a backup copy of my original init file
> so that I can remove those not requested addictions.. and this is very
> annoying...

Angelo, would you open a bug on this matter so that we can track it properly,
and you'll be included on the discussion? I do think this should be fixed by
saving the settings to a separate file -- at least, based on this cursory
discussion. Perhaps the experts in this area have better reasons than we've
heard so far.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Angelo Graziosi]

Il 18/02/2016 00:05, John Wiegley ha scritto:
>>>>>> Angelo Graziosi <angelo.graziosi@alice.it> writes:
>
>> Since this was added to Emacs, I have a backup copy of my original init file
>> so that I can remove those not requested addictions.. and this is very
>> annoying...
>
> Angelo, would you open a bug on this matter so that we can track it properly,
> and you'll be included on the discussion? I do think this should be fixed by
> saving the settings to a separate file -- at least, based on this cursory
> discussion. Perhaps the experts in this area have better reasons than we've
> heard so far.

Done. You should see it as bug #22727.

Ciao,
  Angelo.

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Artur Malabarba]

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

On 17 Feb 2016 9:05 pm, "John Wiegley" <jwiegley@gmail.com> wrote:
>
> >>>>> Angelo Graziosi <angelo.graziosi@alice.it> writes:
>
> Angelo, would you open a bug on this matter so that we can track it
properly,
> and you'll be included on the discussion?

Since nobody replied to my call for volunteers (and I sadly really can't do
it now), we should probably file a bug and mark it as blocking release 25.

> Perhaps the experts in this area have better reasons than we've
> heard so far.

IIRC, the discussions for this feature included me, Stefan, and Thierry
Volpiatto (amongst other people).
My opinion now is in agreement with yours, John, and with Angelo in that
this should move to a dedicated file (though I originally thought using the
custom settings was a good idea).

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

Re: Option to not automatically customize-save-variable `package-selected-packages'

[raman]

John Wiegley <jwiegley@gmail.com> writes:

In general it's a good idea to put all custom settings in a separate
file -- rather than the init file. As  power user I've done this ever
since I started using custom, since I wanted to be able to continue
editing my init file by hand -- but it's a usage style that could
perhaps be made the default -- since most casual users never discover
this.  Also, the  persisted custom settings get flaky/fragile over time
-- I've never filed a bug because it's hard to track down -- but over
time you see things get truncated -- eg vars whose saved value is a long
list. I presently keep my .customize-emacs file under git  (I also
encrypt it so passwds etc are not visible -- but that's a different
story

) >>>>>> Angelo Graziosi <angelo.graziosi@alice.it> writes:
>
>> Since this was added to Emacs, I have a backup copy of my original init file
>> so that I can remove those not requested addictions.. and this is very
>> annoying...
>
> Angelo, would you open a bug on this matter so that we can track it properly,
> and you'll be included on the discussion? I do think this should be fixed by
> saving the settings to a separate file -- at least, based on this cursory
> discussion. Perhaps the experts in this area have better reasons than we've
> heard so far.

-- 

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Eli Zaretskii]

> Date: Wed, 17 Feb 2016 23:43:10 -0200
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> 
> > Angelo, would you open a bug on this matter so that we can track it properly,
> > and you'll be included on the discussion?
> 
> Since nobody replied to my call for volunteers (and I sadly really can't do it now), we should probably file a bug and mark it as blocking release 25.

I don't see why this should block the release.  It's a very old and
established behavior.  It's okay to discuss changing it, but blocking
the release due to it certainly doesn't sound TRT to me.

> > Perhaps the experts in this area have better reasons than we've
> > heard so far.
> 
> IIRC, the discussions for this feature included me, Stefan, and Thierry Volpiatto (amongst other people).

Can you point to those discussions?  If you mean this one:

  http://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00756.html

then after reading it, I'm none the wiser: I don't see the issue with
saving customizations in a separate file raised there.

I found in this thread the following part:

> > > Unfortunately whenever I install/update packages, it saves
> > > `package-selected-packages' to my customize file. This is a bit annoying as I
> > > share my config with git across multiple machines that have different packages
> > > installed.
> >
> > > While I could alter the definition of `package--save-selected-packages'
> > > myself, I'd think it would be nicer if there was a user option to toggle
> > > this behaviour. The default initialization of `all non-dependencies' seems
> > > to be what I'd always want anyway.
> >
> > This sounds like a reasonable request to me; and I sympathize with emitting
> > such generated data to a potentially user-controlled file. Maybe this data
> > could go into another file entirely?
> 
> Yes, I agree. This has been requested by other people too. This variable should be saved in its own file (at a configurable location), like many other cases of persistent data in Emacs.
> 
> Would someone like to do this? I won't have the time for it ATM.

This seems to be a general complaint about package.el using Custom to
save the data about installed packages.  I see no arguments as to why
it's wrong to use Custom for that.  After all, Custom is our standard
way of saving customizations, so it could be argued that having a
single mechanism through which to control where they are saved is
better than inventing a separate mechanism just for package.el.

> My opinion now is in agreement with yours, John, and with Angelo in that this should move to a dedicated file (though I originally thought using the custom settings was a good idea). 

Please explain why you now think differently.

Thanks.

Re: Option to not automatically customize-save-variable `package-selected-packages'?

[Aaron Ecay]

2016ko otsailak 17an, Artur Malabarba-ek idatzi zuen:
> 
> Yes, I agree. This has been requested by other people too. This variable
> should be saved in its own file (at a configurable location), like many
> other cases of persistent data in Emacs.

+1

Additionally, it would be nice if this file was in a format amenable to
version control (one package per line, sorted).  The present format used
by custom.el is neither, meaning that it’s impossible to use VC to sync
the list of installed packages between machines.

-- 
Aaron Ecay

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Colin Baxter]

>
>> My opinion now is in agreement with yours, John, and with Angelo in
>> that this should move to a dedicated file (though I originally
>> thought using the custom settings was a good idea).
>
> Please explain why you now think differently.
>
> Thanks.


Hope you don't mind me butting in. Perhaps the issue is not that Custom
is used by package.el but the way its used. For example, the old emacs
code browser (ecb) similarly added settings to Custom but the user was
alerted immediately and the old emacs init file backed up. All this
information was delivered to the user by a pop-up.

With package.el, unless you read the message buffer immediately after
list-packages, you'd never know that the init file had been edited.

Best.

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Kaushal Modi]

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

I am in favor of saving the package-selected-packages to a separate file
and would also volunteer to make that change.

It's for these reasons I do not find that variable being saved in
custom-file very useful:
- Sharing the custom-file across machines
- diff of that change is difficult to read as all package names are in one
line. So I always blindly commit the change to that variable as I know that
it will be auto updated by emacs when I install/delete the next package.

Saving this variable to a separate file makes sense to me because:
- This does not need to be git controlled ( I can easily gitignore this
file ).
- All my machines using emacs can have their unique
package-selected-packages file (for example: I don't install all work
related packages on my home machine).

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

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Artur Malabarba]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't see why this should block the release.  It's a very old and
> established behavior.  It's okay to discuss changing it, but blocking
> the release due to it certainly doesn't sound TRT to me.

It's not yet part of a stable release, so if this variable is going to cease
being a custom-variable I'd like to decide that before release.

OTOH, implementing this as a separate file is prone to introduce bugs,
so I guess it would be a bad idea to introduce such functionality so
close to release.

>> > Perhaps the experts in this area have better reasons than we've
>> > heard so far.
>> 
>> IIRC, the discussions for this feature included me, Stefan, and Thierry Volpiatto (amongst other people).
>
> Can you point to those discussions?  If you mean this one:
>
>   http://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00756.html

That link looks right.

> then after reading it, I'm none the wiser: I don't see the issue with
> saving customizations in a separate file raised there.

It wasn't. I just mentioned who participated in the discussion of the
feature as a whole, I never said we weighted the pros and cons of using
custom-save-variable for the persistency.

> This seems to be a general complaint about package.el using Custom to
> save the data about installed packages.  I see no arguments as to why
> it's wrong to use Custom for that.

My reason is that Custom is bad for saving data that gets changed
programatically (not just by the user).

> After all, Custom is our standard way of saving customizations,

The problem is that this is not strictly a customization.

The list of manually installed packages is more akin to the list of
abbrevs, or to `desktop-save-mode's data. That is, it is data that
gets programmatically changed by lisp code, without the user's knowledge.

Just like the abbrev and the desktop data are saved to their own files,
I think the list of selected packages should too.

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Eli Zaretskii]

> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: johnw@gnu.org,  emacs-devel@gnu.org,  angelo.graziosi@alice.it
> Date: Thu, 18 Feb 2016 16:06:42 -0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't see why this should block the release.  It's a very old and
> > established behavior.  It's okay to discuss changing it, but blocking
> > the release due to it certainly doesn't sound TRT to me.
> 
> It's not yet part of a stable release, so if this variable is going to cease
> being a custom-variable I'd like to decide that before release.

It's a little too late for that, I'd say.

> OTOH, implementing this as a separate file is prone to introduce bugs,
> so I guess it would be a bad idea to introduce such functionality so
> close to release.

So what other options are there?

> > This seems to be a general complaint about package.el using Custom to
> > save the data about installed packages.  I see no arguments as to why
> > it's wrong to use Custom for that.
> 
> My reason is that Custom is bad for saving data that gets changed
> programatically (not just by the user).
> 
> > After all, Custom is our standard way of saving customizations,
> 
> The problem is that this is not strictly a customization.
> 
> The list of manually installed packages is more akin to the list of
> abbrevs, or to `desktop-save-mode's data. That is, it is data that
> gets programmatically changed by lisp code, without the user's knowledge.
> 
> Just like the abbrev and the desktop data are saved to their own files,
> I think the list of selected packages should too.

I seed your point, but I don't agree.  I see no fundamental difference
between saving the value of a defcustom and saving the list of
packages the user decided to install.

Mechanisms to persist information (Re: Option to not automatically customize-save-variable `package-selected-packages')

[Clément Pit--Claudel]

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

On 02/18/2016 11:49 AM, Eli Zaretskii wrote:
> This seems to be a general complaint about package.el using Custom to
> save the data about installed packages.  I see no arguments as to why
> it's wrong to use Custom for that.  After all, Custom is our standard
> way of saving customizations, so it could be argued that having a
> single mechanism through which to control where they are saved is
> better than inventing a separate mechanism just for package.el.

One thing that I would find convenient as a package developer is a notion of package-local storage. Right now, if I (as a package developer) want to persist information between Emacs sessions, I can either:

* Save the customization through Custom
* Create my own file in user-emacs-directory

The first one is unsuitable for persisted information that shouldn't be presented to the user (for example, if my package collects statistics, I don't want to change the custom file constantly and add large amounts of data to it). The second one in not uniform across packages, and forces me to invent my own storage format (some packages store a lisp form, other store a series of command that are just executed upon loading the file (viper, history), others use json or csv-like formats (as was suggested for package.el)).

In both cases, removing a package won't remove the storage that it uses (either in Custom or in separate files in .emacs.d). This is especially problematic when trying out packages: I launch a package to try it out, it initializes its backing store (often with a file, sometimes with an entry in custom-set-variables), then I remove it (if I don't like it), and yet the backing store is not removed. Take viper as an example (though viper is bundled with Emacs right now): launching it and allowing it to persist its settings creates a file ~/.emacs.d/viper.

It would be nice to have a uniform way to persist package-specific information; ideally one that would collaborate with package.el, so that removing a package would remove its stored state. One would need to figure out how to handle settings persisted through custom as well, but a simple key-value store that plays well with package.el would be a great start.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Option to not automatically customize-save-variable `package-selected-packages'

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> Since nobody replied to my call for volunteers (and I sadly really can't do
>> it now), we should probably file a bug and mark it as blocking release 25.

> I don't see why this should block the release. It's a very old and
> established behavior. It's okay to discuss changing it, but blocking the
> release due to it certainly doesn't sound TRT to me.

Agreed, Eli, this does not need to block release.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Mechanisms to persist information

[Eli Zaretskii]

> From: Clément Pit--Claudel <clement.pit@gmail.com>
> Date: Thu, 18 Feb 2016 13:25:49 -0500
> 
> One thing that I would find convenient as a package developer is a notion of package-local storage.

We will find a lot of missing infrastructure as we begin using
package.el more and more.  This is just the tip of the iceberg.

FWIW, I think we should first design the package system we want to
support, and only after that talk about stuff like saving
package-specific settings.  But I have no illusions that this will be
accepted, or that the discussions will indeed be deferred.

> * Save the customization through Custom
> * Create my own file in user-emacs-directory
> 
> The first one is unsuitable for persisted information that shouldn't be presented to the user (for example, if my package collects statistics, I don't want to change the custom file constantly and add large amounts of data to it). The second one in not uniform across packages, and forces me to invent my own storage format (some packages store a lisp form, other store a series of command that are just executed upon loading the file (viper, history), others use json or csv-like formats (as was suggested for package.el)).

Personally, I see nothing wrong with each package using its own
storage format.  We don't require package authors to use the same
coding style and the same abstractions, so why should storage be any
different?

> In both cases, removing a package won't remove the storage that it uses (either in Custom or in separate files in .emacs.d). This is especially problematic when trying out packages: I launch a package to try it out, it initializes its backing store (often with a file, sometimes with an entry in custom-set-variables), then I remove it (if I don't like it), and yet the backing store is not removed. Take viper as an example (though viper is bundled with Emacs right now): launching it and allowing it to persist its settings creates a file ~/.emacs.d/viper.
> 
> It would be nice to have a uniform way to persist package-specific information; ideally one that would collaborate with package.el, so that removing a package would remove its stored state. One would need to figure out how to handle settings persisted through custom as well, but a simple key-value store that plays well with package.el would be a great start.

Removing auxiliary files doesn't require those files to be in the same
format, it can be solved by having each package produce a record of
those files that the manager can use to delete them.

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Angelo Graziosi]

Maybe I am wrong but Aquamacs does this way. It saves all things in

(custom-set-variables
...
)

in another file..

  Angelo

Il 18/02/2016 17:19, raman ha scritto:
> John Wiegley <jwiegley@gmail.com> writes:
>
> In general it's a good idea to put all custom settings in a separate
> file -- rather than the init file. As  power user I've done this ever
> since I started using custom, since I wanted to be able to continue
> editing my init file by hand -- but it's a usage style that could
> perhaps be made the default -- since most casual users never discover
> this.  Also, the  persisted custom settings get flaky/fragile over time
> -- I've never filed a bug because it's hard to track down -- but over
> time you see things get truncated -- eg vars whose saved value is a long
> list. I presently keep my .customize-emacs file under git  (I also
> encrypt it so passwds etc are not visible -- but that's a different
> story
>
> ) >>>>>> Angelo Graziosi <angelo.graziosi@alice.it> writes:
>>
>>> Since this was added to Emacs, I have a backup copy of my original init file
>>> so that I can remove those not requested addictions.. and this is very
>>> annoying...
>>
>> Angelo, would you open a bug on this matter so that we can track it properly,
>> and you'll be included on the discussion? I do think this should be fixed by
>> saving the settings to a separate file -- at least, based on this cursory
>> discussion. Perhaps the experts in this area have better reasons than we've
>> heard so far.
>

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Eli Zaretskii]

> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Date: Thu, 18 Feb 2016 19:55:25 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> Maybe I am wrong but Aquamacs does this way. It saves all things in
> 
> (custom-set-variables
> ...
> )
> 
> in another file..

Emacs can do that as well, see my other message where I mentioned the
relevant option.

Re: Mechanisms to persist information

[Jonathan Leech-Pepin]

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

On 18 February 2016 at 13:54, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Clément Pit--Claudel <clement.pit@gmail.com>
> > Date: Thu, 18 Feb 2016 13:25:49 -0500
> >
> > One thing that I would find convenient as a package developer is a
> notion of package-local storage.
>
> We will find a lot of missing infrastructure as we begin using
> package.el more and more.  This is just the tip of the iceberg.
>
> FWIW, I think we should first design the package system we want to
> support, and only after that talk about stuff like saving
> package-specific settings.  But I have no illusions that this will be
> accepted, or that the discussions will indeed be deferred.
>
> > * Save the customization through Custom
> > * Create my own file in user-emacs-directory
> >
> > The first one is unsuitable for persisted information that shouldn't be
> presented to the user (for example, if my package collects statistics, I
> don't want to change the custom file constantly and add large amounts of
> data to it). The second one in not uniform across packages, and forces me
> to invent my own storage format (some packages store a lisp form, other
> store a series of command that are just executed upon loading the file
> (viper, history), others use json or csv-like formats (as was suggested for
> package.el)).
>
> Personally, I see nothing wrong with each package using its own
> storage format.  We don't require package authors to use the same
> coding style and the same abstractions, so why should storage be any
> different?
>
> > In both cases, removing a package won't remove the storage that it uses
> (either in Custom or in separate files in .emacs.d). This is especially
> problematic when trying out packages: I launch a package to try it out, it
> initializes its backing store (often with a file, sometimes with an entry
> in custom-set-variables), then I remove it (if I don't like it), and yet
> the backing store is not removed. Take viper as an example (though viper is
> bundled with Emacs right now): launching it and allowing it to persist its
> settings creates a file ~/.emacs.d/viper.
> >
> > It would be nice to have a uniform way to persist package-specific
> information; ideally one that would collaborate with package.el, so that
> removing a package would remove its stored state. One would need to figure
> out how to handle settings persisted through custom as well, but a simple
> key-value store that plays well with package.el would be a great start.
>
> Removing auxiliary files doesn't require those files to be in the same
> format, it can be solved by having each package produce a record of
> those files that the manager can use to delete them.
>
>
A possible implementation for auxiliary files that would reduce the need
for tracking the files could be something akin to:

    (defcustom user-package-data-directory
      (expand-file-name "package-data"
                        user-emacs-directory)
      "Directory for storing persistent package-related data.

    Installation of a package creates a subdirectory for local persistent
    data that will be removed on package uninstallation."
      :type 'directory)

Then part of package installation process would become:

    (make-directory (expand-file-name packagename
                                      user-package-data-directory))

Package removal would simply remove that directory (and it's contents).

Regards,
Jonathan

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

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Joost Kremers]

On Thu, Feb 18 2016, Eli Zaretskii <eliz@gnu.org> wrote:
> I see no fundamental difference
> between saving the value of a defcustom and saving the list of
> packages the user decided to install.

I think the main difference is that as a user, I can decide *not* to use
Customize to set a particular defcustom. I can use a setq in my init
file instead.

My ~/.emacs.d directory is in Dropbox and is shared across three
computers. For certain reasons, not all settings are identical across
the three machines. I use Customize for those settings that are
identical, and I use setq's in my init file to handle those cases where
I want different values for a defcustom.

In the same way, I have different collections of installed packages on
each computer. If the list of installed packages is saved in
custom-set-variables, it'll get sync'ed across my three computers, but
it won't reflect the actual list of packages on each machine. (Either
that, or I'll have a bunch of conflicted copies of the file where I keep
my Customize settings.)

I can see the logic behind saving the list of user-installed packages in
custom-set-variables, but IMHO the user should have the option of
specifying a different location for saving this info. I would keep it
outside ~/.emacs.d, just as I keep `package-user-dir' outside ~/.emacs.d.


-- 
Joost Kremers
Life has its moments

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Cc: Artur Malabarba <bruce.connor.am@gmail.com>, johnw@gnu.org, angelo.graziosi@alice.it, emacs-devel@gnu.org
> Date: Thu, 18 Feb 2016 21:34:48 +0100
> 
> On Thu, Feb 18 2016, Eli Zaretskii <eliz@gnu.org> wrote:
> > I see no fundamental difference
> > between saving the value of a defcustom and saving the list of
> > packages the user decided to install.
> 
> I think the main difference is that as a user, I can decide *not* to use
> Customize to set a particular defcustom. I can use a setq in my init
> file instead.

Can't you do the same with the list of installed packages?

> I can see the logic behind saving the list of user-installed packages in
> custom-set-variables, but IMHO the user should have the option of
> specifying a different location for saving this info.

Sorry, but I still don't see why.

You say that, for certain reasons, the customizations made by
package.el are "special", and due to that you'd like them to be
separate.  But how is this different from any other particular
customization that just happens to be special in some way?  I can
easily imagine a use case where it is inconvenient to have a
particular defcustom saved together with the others, for whatever
reasons.  And yet we don't provide any way of doing that, within the
framework of saving customizations via Custom.  In effect, we say to
such users: do it yourself in Lisp.  Which IMO is a reasonable
response, since users who have such special situations are most
probably capable enough to write their initializations in Lisp,
whereas Custom is for newbies who can't.

Why cannot the same reasoning be applied to the issue at hand?

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Joost Kremers]

On Thu, Feb 18 2016, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Joost Kremers <joostkremers@fastmail.fm>
>> Cc: Artur Malabarba <bruce.connor.am@gmail.com>, johnw@gnu.org, angelo.graziosi@alice.it, emacs-devel@gnu.org
>> Date: Thu, 18 Feb 2016 21:34:48 +0100
>> 
>> On Thu, Feb 18 2016, Eli Zaretskii <eliz@gnu.org> wrote:
>> > I see no fundamental difference
>> > between saving the value of a defcustom and saving the list of
>> > packages the user decided to install.
>> 
>> I think the main difference is that as a user, I can decide *not* to use
>> Customize to set a particular defcustom. I can use a setq in my init
>> file instead.
>
> Can't you do the same with the list of installed packages?

Can I? It was my understanding that package.el will write the list of
user-installed packages to custom-set-variables and there's no way for
the user to prevent this from happening. A quick look at the code of
package.el (on emacs-25 and on master) seems to suggest this is indeed
the case: `package--save-selected-packages' is added to
`after-init-hook' and the function itself appears to save the package
list unconditionally.

Or am I overlooking something?


-- 
Joost Kremers
Life has its moments

Re: Option to not automatically customize-save-variable `package-selected-packages'

[alex]

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

Eli Zaretskii <eliz@gnu.org> writes:

> This seems to be a general complaint about package.el using Custom to
> save the data about installed packages. I see no arguments as to why
> it's wrong to use Custom for that.

There's two major issues that I have in this instance:

1) The user is barely notified that the variable is being saved. In other instances (such as the Customize interface), it's quite obvious that it's going to change your customize file. Installing/upgrading packages changes the file with no obvious notice or prompt (as the notice gets drowned out by the package install/upgrade/delete messages). It's also not obvious at all that your customize file is going to change from those actions (it hasn't since these actions were created).

2) The package list for a particular user can differ between different machines. This makes it annoying to share a config among the machine with something like git. I think this data would be better suited to a separate place where it's easy go gitignore it, like with abbrevs, recentf and so on. It's tied not only to the customization in the init file but also outside state (that is, any packages installed/deleted outside of your init file).

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

Re: Option to not automatically customize-save-variable `package-selected-packages'

[alex]

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

Eli Zaretskii <eliz@gnu.org> writes:

> So what other options are there?

At the very least the automatic saving of the package list should be optional, even if it is to the customize file. Even just a simple defcustom that does that would be helpful.

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

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Cc: bruce.connor.am@gmail.com, johnw@gnu.org, angelo.graziosi@alice.it, emacs-devel@gnu.org
> Date: Thu, 18 Feb 2016 22:49:52 +0100
> 
> >> I think the main difference is that as a user, I can decide *not* to use
> >> Customize to set a particular defcustom. I can use a setq in my init
> >> file instead.
> >
> > Can't you do the same with the list of installed packages?
> 
> Can I? It was my understanding that package.el will write the list of
> user-installed packages to custom-set-variables and there's no way for
> the user to prevent this from happening. A quick look at the code of
> package.el (on emacs-25 and on master) seems to suggest this is indeed
> the case: `package--save-selected-packages' is added to
> `after-init-hook' and the function itself appears to save the package
> list unconditionally.

Is package--save-selected-packages called every time package.el is
invoked, even if the user doesn't change the list of the selected
packages?  If so, this is the problem we must solve -- package.el
shouldn't write anything to user files if nothing's changed in the
selected packages.

Otherwise, the user could install a package, edit their .emacs to
convert the custom-set-variables forms into setq, and then write more
complex Lisp if the init file needs to be shared across different
systems with different collections of packages on each system, like
they have to do with any other customization that is system-dependent.

Will this solve the issue?

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Eli Zaretskii]

> Date: Thu, 18 Feb 2016 22:08:18 -0500
> From: alex <current@protonmail.com>
> 
> > This seems to be a general complaint about package.el using Custom to
> > save the data about installed packages. I see no arguments as to why
> > it's wrong to use Custom for that.
> 
> There's two major issues that I have in this instance:
> 
> 1) The user is barely notified that the variable is being saved. In other instances (such as the Customize
> interface), it's quite obvious that it's going to change your customize file. Installing/upgrading packages
> changes the file with no obvious notice or prompt (as the notice gets drowned out by the package
> install/upgrade/delete messages). It's also not obvious at all that your customize file is going to change from
> those actions (it hasn't since these actions were created).

What would the prompt say in this case?  If it suggests not to save
the selected packages with the other customizations, and the user opts
not to save, wouldn't that mean Emacs will not know these packages
weer selected next time it starts?  If so, letting the user choose
that alternative would be a disservice, I think.

> 2) The package list for a particular user can differ between different machines. This makes it annoying to
> share a config among the machine with something like git. I think this data would be better suited to a separate
> place where it's easy go gitignore it, like with abbrevs, recentf and so on. It's tied not only to the customization
> in the init file but also to the state of the computer itself (that is, any packages installed/deleted outside of your
> init file).

As I wrote elsewhere, this could happen with any other customized
variable, and we currently don't have any solution for that except
expecting the affected users to write some Lisp to solve this.  I see
no reason yet why this particular customization is different as to
require a specialized solution just for it.  Can you tell why you
think it is different?

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Angelo Graziosi]

I am afraid but also for this thread I would prefer what I wrote at

   http://lists.gnu.org/archive/html/bug-gnu-emacs/2016-02/msg01079.html


p. 4, i.e.

"This thread seems to have all the prerequisites to become another of 
those endless thread, so please [...] remove me from the discussion."


   Thanks,
     Angelo.

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Eli Zaretskii]

> Date: Thu, 18 Feb 2016 23:18:30 -0500
> From: alex <current@protonmail.com>
> Cc: Artur Malabarba <bruce.connor.am@gmail.com>, johnw@gnu.org, angelo.graziosi@alice.it, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So what other options are there?
> 
> At the very least the automatic saving of the package list should be optional, even if it is to the customize file.
> Even just a simple defcustom that does that would be helpful.

Wouldn't that hamper the operation of package.el next time it is
invoked in a new Emacs session?  If not, then why do we save this
information at all?  If it doesn't help, it shouldn't be saved, IMO.

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Artur Malabarba]

Eli Zaretskii <eliz@gnu.org> writes:

> Is package--save-selected-packages called every time package.el is
> invoked, even if the user doesn't change the list of the selected
> packages?

No. But it is called every time the list changes (either by installing
or deleting a package).

> Otherwise, the user could install a package, edit their .emacs to
> convert the custom-set-variables forms into setq, [...] like
> they have to do with any other customization that is system-dependent.
>
> Will this solve the issue?

No, because package.el will still call `package--save-selected-packages'
even though the variable has been set via `setq'. This will keep
modifying the custom file, and the behaviour will depend on whether when
the variable's value has been most recently set from the `setq' or from
Custom.

Meanwhile, with regular customizations, the user can just turn the
`custom-set-variables' call into a `setq' and trust that Emacs won't
reintroduce that variable there.

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Eli Zaretskii]

> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: Joost Kremers <joostkremers@fastmail.fm>,  johnw@gnu.org,  angelo.graziosi@alice.it,  emacs-devel@gnu.org
> Date: Fri, 19 Feb 2016 11:04:23 -0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Is package--save-selected-packages called every time package.el is
> > invoked, even if the user doesn't change the list of the selected
> > packages?
> 
> No. But it is called every time the list changes (either by installing
> or deleting a package).
> 
> > Otherwise, the user could install a package, edit their .emacs to
> > convert the custom-set-variables forms into setq, [...] like
> > they have to do with any other customization that is system-dependent.
> >
> > Will this solve the issue?
> 
> No, because package.el will still call `package--save-selected-packages'
> even though the variable has been set via `setq'. This will keep
> modifying the custom file, and the behaviour will depend on whether when
> the variable's value has been most recently set from the `setq' or from
> Custom.

Then I guess this is the problem we need to solve, right?  Customizing
the list of packages via Lisp that doesn't use custom-set-variables
ought to prevent Emacs from modifying the custom file.

> Meanwhile, with regular customizations, the user can just turn the
> `custom-set-variables' call into a `setq' and trust that Emacs won't
> reintroduce that variable there.

Now I'm confused: above you said "No" to my suggestion to do exactly
this, but now you seem to say that suggestion would solve the problem?
What did I miss?

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Artur Malabarba]

Eli Zaretskii <eliz@gnu.org> writes:

>> No, because package.el will still call `package--save-selected-packages'
>> modifying the custom file, and the behaviour will depend on whether when
>> even though the variable has been set via `setq'. This will keep
>> the variable's value has been most recently set from the `setq' or from
>> Custom.
>
> Then I guess this is the problem we need to solve, right?  Customizing
> the list of packages via Lisp that doesn't use custom-set-variables
> ought to prevent Emacs from modifying the custom file.

This would allow people to set it via setq, but that's not the prevalent
complaint I see on this thread.

Another complaint I see is “I don't want my custom (or init) file being
programatically altered, for reason X”. These complaints don't want to
manually keep track of their packages with a `setq'. They want
package.el to keep working its magic automatically, but keep its hands
off their custom files.

>> Meanwhile, with regular customizations, the user can just turn the
>> `custom-set-variables' call into a `setq' and trust that Emacs won't
>> reintroduce that variable there.
>
> Now I'm confused: above you said "No" to my suggestion to do exactly
> this, but now you seem to say that suggestion would solve the problem?
> What did I miss?

This sentence is explaining why _regular custom variables_ don't have
the problem that `package-selected-packages' has.

- _Regular custom variables_ don't get saved to the custom file without
  explicit user request, so it's easy to turn them into `setq's (which
  is what you were discussing).

- OTOH, `package-selected-packages' _does_ get saved without explicit
  request, so it's hard for the user to turn it into a `setq'.

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Eli Zaretskii]

> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: joostkremers@fastmail.fm,  johnw@gnu.org,  emacs-devel@gnu.org
> Date: Fri, 19 Feb 2016 16:29:17 -0200
> 
> Another complaint I see is “I don't want my custom (or init) file being
> programatically altered, for reason X”. These complaints don't want to
> manually keep track of their packages with a `setq'. They want
> package.el to keep working its magic automatically, but keep its hands
> off their custom files.

I tried to figure out why people feel like that about this particular
customization, but couldn't.  I asked the question about that several
times, but either didn't get an answer, or didn't understand it.  I'd
still like to understand what's so special about this particular
customization.

> This sentence is explaining why _regular custom variables_ don't have
> the problem that `package-selected-packages' has.
> 
> - _Regular custom variables_ don't get saved to the custom file without
>   explicit user request, so it's easy to turn them into `setq's (which
>   is what you were discussing).
> 
> - OTOH, `package-selected-packages' _does_ get saved without explicit
>   request, so it's hard for the user to turn it into a `setq'.

Ah, okay, thanks.  So preventing package.el from doing that should
solve at least part of the problem.  Would someone please work on
that?

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Kaushal Modi]

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

On Fri, Feb 19, 2016 at 1:50 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> I'd
> still like to understand what's so special about this particular
> customization.
>

IMO this particular customization is not portable across multiple machines.
All machines need not have the same packages installed; reasons: different
emacs versions, one machine begin at work, another at home, etc.

Another reason is that this variable is more like persistent data cache
which updates very frequently (unlike the other customization options which
a user typically sets and does "Save for future sessions"). In the former
case, user has no control on what this variable is set to; in the latter
case, user has total control.

Also the value stored in this variable is more of use to package.el than
directly to the user. The train of thought is that user doesn't care what
this variable is set to. But a user would care if delete-selection-mode is
set to nil/t.

Also frequent changing of this variable value causes noise in git commits
(if a user is saving their config using git); the diff of this variable
change is not very helpful as usually people have lots of packages
installed and a glance at the diff doesn't tell instantly which package was
added/removed. In crux, committing of custom-file causes non-useful
commits. That brings back to the earlier point that as this variable is
machine-specific, they do not need to be in a file which a user would
typically share among machines. If I am used to delete-selection-mode on
one machine, that stays true when I am using emacs on my other machine too.


--
Kaushal Modi

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

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Fri, 19 Feb 2016 14:05:29 -0500
> Cc: Artur Malabarba <bruce.connor.am@gmail.com>, joostkremers@fastmail.fm, 
> 	John Wiegley <johnw@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
>  I'd
>  still like to understand what's so special about this particular
>  customization.
> 
> IMO this particular customization is not portable across multiple machines. All machines need not have the
> same packages installed; reasons: different emacs versions, one machine begin at work, another at home,
> etc.

I have the same problem with a lot of my customizations.  I don't see
why this one is different.

> Another reason is that this variable is more like persistent data cache which updates very frequently (unlike
> the other customization options which a user typically sets and does "Save for future sessions").

Why is frequency relevant to where the settings are saved?

> In the
> former case, user has no control on what this variable is set to; in the latter case, user has total control.

I think the user has control in the latter case as well: it is the
user who decides to install or uninstall packages.

> Also the value stored in this variable is more of use to package.el than directly to the user. The train of thought
> is that user doesn't care what this variable is set to. But a user would care if delete-selection-mode is set to
> nil/t.

The user should care about these settings because she wants the same
packages to be available in future sessions.  Same as with any other
persistent customization.

> Also frequent changing of this variable value causes noise in git commits (if a user is saving their config using
> git); the diff of this variable change is not very helpful as usually people have lots of packages installed and a
> glance at the diff doesn't tell instantly which package was added/removed. In crux, committing of custom-file
> causes non-useful commits. That brings back to the earlier point that as this variable is machine-specific,
> they do not need to be in a file which a user would typically share among machines. If I am used to
> delete-selection-mode on one machine, that stays true when I am using emacs on my other machine too.

Again, not very different from any other customization that differs
between machines.  Users should be able to replace Custom forms with
plain Lisp code, and then they could resolve the issues with sharing
the settings across different machines and with Git easier.

I already said all of that several times, so I will now shut up,
unconvinced.

Re: Option to not automatically customize-save-variable `package-selected-packages'

[alex]

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

Eli Zaretskii <eliz@gnu.org> writes:
> Wouldn't that hamper the operation of package.el next time it is
> invoked in a new Emacs session?

It depends on how the variable is being used, I suppose. There is a function `package-install-selected-packages' that may be used to install packages from this list if it's not empty.
However, many people may choose not to use this functionality as they are used to or prefer other methods (such as use-package, which I find much better). If one doesn't use this function (or `package-autoremove'), then there's no need to save it.

So I don't believe that the persistence of the list is necessary for all users. It could save some time for it to calculate the default, which is why saving it could be somewhat useful in some cases.

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

Re: Option to not automatically customize-save-variable `package-selected-packages'

[alex]

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

Eli Zaretskii <eliz@gnu.org> writes:

> What would the prompt say in this case?

Perhaps something along the lines of "Save <package> permanently to package-selected-packages? (y or n)". Then a variable can be introduced to determine whether or not this prompt should be displayed, or if it should even be saved at all. A variable similar to this is `vc-follow-symlinks', which can have the values nil, ask, or t.

> wouldn't that mean Emacs will not know these packages
> weer selected next time it starts?

Yes, so if you relied on its functionality then it could cause issues. This would be something for the user to decide.

>I see no reason yet why this particular customization is different as to
> require a specialized solution just for it. Can you tell why you
> think it is different?

I do write Lisp for almost all of my customizations, but this isn't really a case where I think behaviour should be handed off to the users to manually tune. For instance, I don't want to have custom Lisp in my init file handling all of my abbrevs, yasnippets, or words in my personal Emacs dictionary. All of these have their own files to which they save data to. I think that the list of `selected' packages, if saved, should go to its own file like the above.

Other customized variables are easy to maintain. `package-selected-packages' on the other hand is a bit more dynamic and can become quite large and difficult to maintain.

I can't use the customize interface for this variable since as far as I'm aware the customize file isn't great for conditionally assigning variables depending on other variables at run-time (like system-type), though perhaps I'm wrong.

So customize seems to be out of the picture here. Without a separate save file, I'd have to use my init file for the job. Certainly it's possible to conditionally setq the variable depending on the machine state, but this can become quite unwieldy with a large number of packages, and with more and more different machines with different packages that you want in this list. There could be a lot of work needed to manually change all of these branches for every package installed/removed.

When I save an abbrev or a dictionary word, I don't want to manually edit my init file corresponding to that. Likewise, I'd rather not have to edit this variable every time I add/drop a package. A separate file, that can be made machine-specific, that holds this data would mean that the users don't have to edit it themselves, nor do they have to worry about the variable being overwritten when the same configuration is moved to a different machine and back.

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

Re: Mechanisms to persist information (Re: Option to not automatically customize-save-variable `package-selected-packages')

[John Wiegley]

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

>>>>> Clément Pit--Claudel <clement.pit@gmail.com> writes:

> It would be nice to have a uniform way to persist package-specific
> information; ideally one that would collaborate with package.el, so that
> removing a package would remove its stored state. One would need to figure
> out how to handle settings persisted through custom as well, but a simple
> key-value store that plays well with package.el would be a great start.

This sounds like a pretty useful core library to me.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Mechanisms to persist information (Re: Option to not automatically customize-save-variable `package-selected-packages')

[Eric Abrahamsen]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Clément Pit--Claudel <clement.pit@gmail.com> writes:
>
>> It would be nice to have a uniform way to persist package-specific
>> information; ideally one that would collaborate with package.el, so that
>> removing a package would remove its stored state. One would need to figure
>> out how to handle settings persisted through custom as well, but a simple
>> key-value store that plays well with package.el would be a great start.
>
> This sounds like a pretty useful core library to me.

I've been using eieio-persistent for things like this.

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Eli Zaretskii]

> Date: Fri, 19 Feb 2016 16:15:41 -0500
> From: alex <current@protonmail.com>
> Cc: bruce.connor.am@gmail.com, johnw@gnu.org, emacs-devel@gnu.org
> 
> It depends on how the variable is being used, I suppose. There is a function
> `package-install-selected-packages' that may be used to install packages from this list if it's not empty. 
> However, many people may choose not to use this functionality as they are used to or prefer other methods
> (such as use-package, which I find much better). If one doesn't use this function (or `package-autoremove'),
> then there's no need to save it.
> 
> So I don't believe that the persistence of the list is necessary for all users. It could save some time for it to
> calculate the default, which is why saving it could be somewhat useful in some cases.

If the value can be calculated, then it doesn't need to be saved, I
agree.

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Eli Zaretskii]

> Date: Fri, 19 Feb 2016 17:55:21 -0500
> From: alex <current@protonmail.com>
> Cc: johnw@gnu.org, emacs-devel@gnu.org, bruce.connor.am@gmail.com
> 
> I can't use the customize interface for this variable since as far as I'm aware the customize file isn't great for
> conditionally assigning variables depending on other variables at run-time (like system-type), though perhaps
> I'm wrong.

I think you are wrong.

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Joost Kremers]

On Fri, Feb 19 2016, Eli Zaretskii <eliz@gnu.org> wrote:
> Again, not very different from any other customization that differs
> between machines.  Users should be able to replace Custom forms with
> plain Lisp code, and then they could resolve the issues with sharing
> the settings across different machines and with Git easier.
>
> I already said all of that several times, so I will now shut up,
> unconvinced.

Unconvinced of what, if I may ask?

And what has now been decided (if anything)? Will there be an option to
keep package.el from writing `package-selected-packages' to
`custom-set-variables'? And what will happen if I set this option? Do I
*have* to setq `package-selected-packages' or can I also leave it nil?
Should I expect any adverse effects if I do that (other than the fact
that packages won't be installed automatically, of course). Since I use
use-package anyway, I'd prefer it if I could just leave
`package-selected-packages' unset.



-- 
Joost Kremers
Life has its moments

Re: Option to not automatically customize-save-variable `package-selected-packages'

[John Wiegley]

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

>>>>> Joost Kremers <joostkremers@fastmail.fm> writes:

> And what has now been decided (if anything)? Will there be an option to keep
> package.el from writing `package-selected-packages' to
> `custom-set-variables'? And what will happen if I set this option? Do I
> *have* to setq `package-selected-packages' or can I also leave it nil?
> Should I expect any adverse effects if I do that (other than the fact that
> packages won't be installed automatically, of course). Since I use
> use-package anyway, I'd prefer it if I could just leave
> `package-selected-packages' unset.

The customization interface, like code written in a .emacs file, represents
manual changes initiated by the user. These should go into a file they keep
under version control, as a record of how they have personalized their Emacs
environment.

Changes beyond that, such as `package-selected-packages', that are not
configured by the user directly, but are changed and persisted by code running
in Emacs, should be saved to the user-data-directory in a file specific to
that package. The ideal for doing this would be a new persistence API that
packages can rely on to do the right thing whenever needed.

The general principle is that, if you keep a file under version control, it
should change only when you know you've made changes affecting that file.
Generated data outside of Customize should not make changes to that file.

One might say that selecting packages represents a flavor of customization,
and I'd be open to hearing that argument; but enough people have expressed
surprise and dislike about this that I feel the data should be persisted in a
location dedicated to that purpose.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Cc: Kaushal Modi <kaushal.modi@gmail.com>, johnw@gnu.org, bruce.connor.am@gmail.com, emacs-devel@gnu.org
> Date: Mon, 22 Feb 2016 00:56:40 +0100
> 
> 
> On Fri, Feb 19 2016, Eli Zaretskii <eliz@gnu.org> wrote:
> > Again, not very different from any other customization that differs
> > between machines.  Users should be able to replace Custom forms with
> > plain Lisp code, and then they could resolve the issues with sharing
> > the settings across different machines and with Git easier.
> >
> > I already said all of that several times, so I will now shut up,
> > unconvinced.
> 
> Unconvinced of what, if I may ask?

Of the need to have a separate file for this.

Re: Option to not automatically customize-save-variable `package-selected-packages'

[Bastian Beischer]

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

Dear all,

I'm not an emacs developer, but one thing which wasn't brought up in this
discussion so far is the following:

The entry in custom-set-variables changes continuously even if no new
packages are installed, mainly whenever you update the packages: That will
perform an uninstall of the old package and re-install of the same package
with the new version. I don't change the list of installed packages often,
but I do update my packages frequently and every time my .emacs changes. I
find this annoying since I keep the .emacs file under version control.

On Mon, Feb 22, 2016 at 4:37 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Joost Kremers <joostkremers@fastmail.fm>
> > Cc: Kaushal Modi <kaushal.modi@gmail.com>, johnw@gnu.org,
> bruce.connor.am@gmail.com, emacs-devel@gnu.org
> > Date: Mon, 22 Feb 2016 00:56:40 +0100
> >
> >
> > On Fri, Feb 19 2016, Eli Zaretskii <eliz@gnu.org> wrote:
> > > Again, not very different from any other customization that differs
> > > between machines.  Users should be able to replace Custom forms with
> > > plain Lisp code, and then they could resolve the issues with sharing
> > > the settings across different machines and with Git easier.
> > >
> > > I already said all of that several times, so I will now shut up,
> > > unconvinced.
> >
> > Unconvinced of what, if I may ask?
>
> Of the need to have a separate file for this.
>
>


-- 
Bastian Beischer
RWTH Aachen University of Technology

@RWTH Aachen
Office: 28 C 203
Phone: +49-241-80-27205
E-mail: beischer@physik.rwth-aachen.de
Address: I. Physikalisches Institut B, Sommerfeldstr. 14, D-52074 Aachen

@CERN
Office: Bdg 32-4-B12
Phone: +41-22-76-75750
E-mail: bastian.beischer@cern.ch
Address: CERN, CH-1211 Geneve 23

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

Re: Option to not automatically customize-save-variable `package-selected-packages'

[alex]

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

Eli Zaretskii <eliz@gnu.org> writes:
> I think you are wrong.

Maybe, but the manual doesn't seem to mention such functionality. Can one use
customize in a way such that for different variables it runs a user-specified
conditional and reads/writes the result depending on the result? For instance,
is there way to customize the variable foo so that customize would keep track
of two separate instances of foo -- one for when a user-specified predicate is
true, and one when it's not? Then if one wanted to read/write this variable,
the `proper' one would accessed?

Anyway, I don't think that's important. More importantly, is there an agreement
that Emacs shouldn't automatically save this variable, or at least offer the
option to not automatically save it?

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