From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH 3/3] emacs: Add "Source" field to 'guix-info' buffers. Date: Sun, 09 Nov 2014 23:43:24 +0100 Message-ID: <87d28wq9kj.fsf@gnu.org> References: <87egtcbwd0.fsf@gmail.com> <87lhnktgh7.fsf@gnu.org> <878ujkb475.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52693) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnbCq-00016q-Lm for guix-devel@gnu.org; Sun, 09 Nov 2014 17:43:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XnbCh-0006OU-JA for guix-devel@gnu.org; Sun, 09 Nov 2014 17:43:36 -0500 Received: from hera.aquilenet.fr ([2a01:474::1]:51405) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnbCh-0006ON-4I for guix-devel@gnu.org; Sun, 09 Nov 2014 17:43:27 -0500 In-Reply-To: <878ujkb475.fsf@gmail.com> (Alex Kost's message of "Sun, 09 Nov 2014 21:48:30 +0300") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Alex Kost Cc: guix-devel@gnu.org Alex Kost skribis: > Ludovic Court=C3=A8s (2014-11-09 20:45 +0300) wrote: >> I had in mind a slightly simpler user interface: just a =E2=80=9CView so= urce=E2=80=9D >> button. The thing would build (package-source-derivation p), >> effectively downloading it if it=E2=80=99s not already present, and open= ing it >> in dired. > > I don't think opening in dired should be a default (although I made > =E2=80=98guix-package-info-find-source-p=E2=80=99 variable +for you+ for = this case) :-) > because there may be a big compressed tarball that a user wouldn't like > to uncompress with emacs tar-mode. I think displaying a link is the > preferable variant as a user can open the file or copy its path if he > wants. Oh right, I didn=E2=80=99t think about big tarballs. > Also you suggest to make =E2=80=9CView source=E2=80=9D synchronous: build= a source > derivation, download it and open in dired. Did I understand it right? Yes. > As this process may take a long time (for big sources or for git > checkouts if a user doesn't have a necessary git infrastructure), I > think it should be evaluated asynchronously in a REPL and it's not > possible (at least not easy) to define what value was returned by a REPL > command, so no way to define what file to open in dired. Oh, makes sense. I completely overlooked =E2=80=9Cimplementation details.= =E2=80=9D :-) > Also what if I want to define whether there is a source in the store or > not? (And I don't want to download it if it's not there.) I don=E2=80=99t think it=E2=80=99s natural for a user to think in terms of = downloads. Personally, when I want to see the source of a package, I do: tar xf $(guix build -S foo) and that=E2=80=99s it. If it=E2=80=99s taking too long or something, I can= still hit C-c. But typically, I don=E2=80=99t ask myself =E2=80=9Cis this already in= the store?=E2=80=9D. > With your variant of a single =E2=80=9CView source=E2=80=9D button it wou= ld not be > possible, as the source that doesn't exist in the store will be > downloaded unconditionally. Rather: the result of =E2=80=98package-source-derivation=E2=80=99 would be = built unconditionally; that entails a download if and only if the source is not already in the store, otherwise nothing happens (which you probably already know, but I just want to be clear.) >> With the interface you propose, things might be slightly confusing: >> sometimes clicking on =E2=80=9CDownload=E2=80=9D will do nothing (becaus= e the source is >> already there), sometime =E2=80=9CShow=E2=80=9D will work without =E2=80= =9CDownload=E2=80=9D, sometimes >> not, etc. Also it takes up quite a bit of space. > > Sorry, I didn't get it. What space do you mean? I meant visual space in the user interface; visual clutter. > Pushing a =E2=80=9CDownload=E2=80=9D button will always do something: it = will run some > command in a REPL and will always display a store path in the end. And > =C2=ABHey, USER, what did you expect from a =E2=80=9CDownload=E2=80=9D bu= tton if the source > is already downloaded?=C2=BB Right, but we don=E2=80=99t need the user=E2=80=99s mind to carry part of t= he store=E2=80=99s state: there=E2=80=99s already a database for that. :-) > But if you find it confusing what about the following variant: initially > there will be only =E2=80=9CShow=E2=80=9D button and when you press it, = =E2=80=9CDownload=E2=80=9D > button appears only if the source does not exist in the store. After > a successful downloading, it disappears again. That would work, yes. But note that derivation outputs not obtained by a =E2=80=98build-derivatio= ns=E2=80=99 call with the current store connection may be garbage-collected anytime. That makes it more difficult to reliably determine whether the =E2=80=9CDownload=E2=80=9D button should be displayed; to be safe, it would= have to be displayed by default. Then we=E2=80=99re very close to the current patch, I think, no? If that=E2=80=99s fine with you, perhaps let=E2=80=99s just commit the patc= h as is, and see in another patch whether =E2=80=9CDownload=E2=80=9D can be made to disa= ppear in safe cases? Thanks, Ludo=E2=80=99.