From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jonathan Leech-Pepin Newsgroups: gmane.emacs.devel Subject: Re: Mechanisms to persist information Date: Thu, 18 Feb 2016 14:22:34 -0500 Message-ID: References: <56C43D17.7010009@alice.it> <831t8aufoe.fsf@gnu.org> <56C60CAD.3060308@gmail.com> <83d1rtu9vr.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113d46700f0d36052c104bb1 X-Trace: ger.gmane.org 1455823402 7648 80.91.229.3 (18 Feb 2016 19:23:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Feb 2016 19:23:22 +0000 (UTC) Cc: =?UTF-8?B?Q2zDqW1lbnQgUGl0LS1DbGF1ZGVs?= , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 18 20:23:13 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aWUAT-0006i8-5k for ged-emacs-devel@m.gmane.org; Thu, 18 Feb 2016 20:23:13 +0100 Original-Received: from localhost ([::1]:44689 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWUAS-0002r8-Ho for ged-emacs-devel@m.gmane.org; Thu, 18 Feb 2016 14:23:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33399) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWUAC-0002nD-Cj for emacs-devel@gnu.org; Thu, 18 Feb 2016 14:22:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWUAA-0002mg-UN for emacs-devel@gnu.org; Thu, 18 Feb 2016 14:22:56 -0500 Original-Received: from mail-ob0-x22d.google.com ([2607:f8b0:4003:c01::22d]:35788) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWUAA-0002m9-Ne; Thu, 18 Feb 2016 14:22:54 -0500 Original-Received: by mail-ob0-x22d.google.com with SMTP id xk3so83801668obc.2; Thu, 18 Feb 2016 11:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ai5BJ54M5DI4KWBNfswyGv2BwJHv8jtwzdd2DCFryLU=; b=gQ3Qjod2QIwek1QRxGgQwMebKU4DPoD6TL7ttsOYPzl1+lLQ4duONilYFzDt1I25AW kaqEutXK9FNRYn1OnSCCCBYpthCYe0ZcmT9s51ho5lUkKkjkhE0Zq2ud0+R/lOBvsNFP 8s5D2+QbLg1/Yg48w/nJr2TK2wljCexFEoISF0a1srOyfqHiyFGG+6g+0/i5tZcEmpgQ soc1XLZ1VE2h6rEhcHaONOQoiluH8r2JxTGr+5BJvDGQuJ7wPWuc+0+G+ymg5Xy7qMlS EbXaGGnELVprn97XqKvrekbFFprb2fs0zOqWo3vcOjUZQICA1x/xOzdeNu83j/VcOLps Rk/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ai5BJ54M5DI4KWBNfswyGv2BwJHv8jtwzdd2DCFryLU=; b=X4v+2kTd6xVC0MMd1eqmoJzyLpXnoTcqOZvdISdMtkcKYuLazdpZCv7qsZBJJX7ZTX jTaDnq3QxN6FJZoTj9h7riuwrWNTdIal6o4k0YBTCguuSiyz0DyCgnKyKtwUNwj9Juab OLpL/O3/SPISZL2mb3UgPuaMwV/yaRJCZZAAwZJS+gZ3+ojoSUqqukoM3M2oCjyt8vfN OvvfoBlAW8lnSVOGCQ5bmPQIOPT9TGOJo1LWZ+QQfVKZK6Wbm7Vj2dW1ILSGVl510s6X tTCNr1P9K6DskcArsTAtsKyvmoQ546CN9uFfec2d3uE2tqyTfTzhxXCAyX8f4UTkukgr mLhA== X-Gm-Message-State: AG10YOQFC2s7Vm5l3EaKRSmxUYJngYsGHUzKeI3zb+zeErJw9LQCyEoRXY72p1gP5ynMtaJvbhGeMYmC6wxC7w== X-Received: by 10.202.91.196 with SMTP id p187mr7587397oib.39.1455823373928; Thu, 18 Feb 2016 11:22:53 -0800 (PST) Original-Received: by 10.76.134.67 with HTTP; Thu, 18 Feb 2016 11:22:34 -0800 (PST) In-Reply-To: <83d1rtu9vr.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4003:c01::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:200150 Archived-At: --001a113d46700f0d36052c104bb1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 18 February 2016 at 13:54, Eli Zaretskii wrote: > > From: Cl=C3=A9ment Pit--Claudel > > 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 f= or > 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, i= t > 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 it= s > 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 figur= e > 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 --001a113d46700f0d36052c104bb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 18 February 2016 at 13:54, Eli Zaretskii <eliz@gnu.org> wr= ote:
> From: Cl=C3=A9ment 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 not= ion of package-local storage.

We will find a lot of missing infrastructure as we begin using
package.el more and more.=C2=A0 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.=C2=A0 But I have no illusions that this will be<= br> 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 amoun= ts of data to it). The second one in not uniform across packages, and force= s me to invent my own storage format (some packages store a lisp form, othe= r store a series of command that are just executed upon loading the file (v= iper, history), others use json or csv-like formats (as was suggested for p= ackage.el)).

Personally, I see nothing wrong with each package using its own
storage format.=C2=A0 We don't require package authors to use the same<= br> 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 especial= ly 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 entr= y 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 vipe= r 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 inf= ormation; ideally one that would collaborate with package.el, so that remov= ing a package would remove its stored state. One would need to figure out h= ow to handle settings persisted through custom as well, but a simple key-va= lue 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<= br> 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 implemen= tation for auxiliary files that would reduce the need for tracking the file= s could be something akin to:

=C2=A0 =C2=A0 (defcustom user-package-data-directory
=C2=A0 =C2= =A0 =C2=A0 (expand-file-name "package-data"
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 user-emacs-d= irectory)
=C2=A0 =C2=A0 =C2=A0 "Directory for storing persistent packa= ge-related data.
=C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 Installation of a packa= ge creates a subdirectory for local persistent
=C2=A0 =C2=A0 data that will= be removed on package uninstallation."
=C2=A0 =C2=A0 =C2=A0 :type = 9;directory)

Then part of package installation process would b= ecome:

=C2=A0 =C2=A0 (make-directory (expand-file-name package= name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 user-package= -data-directory))

Package removal would simply remove that dir= ectory (and it's contents).

Regards,
<= div class=3D"gmail_extra">Jonat= han
--001a113d46700f0d36052c104bb1--