Ludovic Courtès (2014-11-10 01:43 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:

[...]

>> 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)

I think later we can provide some variable to choose if pushing a
"source file" button will open a tarball in a ‘tar-mode’ (a usual
'find-file' way) or will untar it in “/tmp” or something.

> 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?”.

I typically ask myself this question :-)

>> 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.)

Yes, I know, I meant that with your variant it's not possible to know if
you already have a source in the store or not: whenever you push “View
source” you will eventually have it there.

>>> 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.

Is that "too much information is bad"?  Do you suggest to remove
something?

>> 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.  :-)

OK.

>> 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?

I just check whether a final source file exists in the store and that's
all.  I think it's reliable, isn't it?

> 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?

I modified the patch (attached) to display “Show” and “Download” buttons
only when needed.  WDYT?

The patch may be applied to the current head (I have pushed a couple of
auxiliary commits).