Re: [PATCH 3/3] emacs: Add "Source" field to 'guix-info' buffers.

[Ludovic Courtès]

Alex Kost <address@hidden> skribis:

> Ludovic Courtès (2014-11-09 20:45 +0300) wrote:
>> I had in mind a slightly simpler user interface: just a “View source”
>> button.  The thing would build (package-source-derivation p),
>> effectively downloading it if it’s not already present, and opening it
>> in dired.
>
> I don't think opening in dired should be a default (although I made
> ‘guix-package-info-find-source-p’ 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’t think about big tarballs.

> Also you suggest to make “View source” 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 “implementation details.”  :-)

> 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’t think it’s 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’s it.  If it’s taking too long or something, I can still hit
C-c.  But typically, I don’t ask myself “is this already in the store?”.

> With your variant of a single “View source” button it would not be
> possible, as the source that doesn't exist in the store will be
> downloaded unconditionally.

Rather: the result of ‘package-source-derivation’ 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 “Download” will do nothing (because the source is
>> already there), sometime “Show” will work without “Download”, 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 “Download” button will always do something: it will run some
> command in a REPL and will always display a store path in the end.  And
> «Hey, USER, what did you expect from a “Download” button if the source
> is already downloaded?»

Right, but we don’t need the user’s mind to carry part of the store’s
state: there’s already a database for that.  :-)

> But if you find it confusing what about the following variant: initially
> there will be only “Show” button and when you press it, “Download”
> 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 ‘build-derivations’
call with the current store connection may be garbage-collected anytime.
That makes it more difficult to reliably determine whether the
“Download” button should be displayed; to be safe, it would have to be
displayed by default.  Then we’re very close to the current patch, I
think, no?

If that’s fine with you, perhaps let’s just commit the patch as is, and
see in another patch whether “Download” can be made to disappear in safe
cases?

Thanks,
Ludo’.