guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ludovic Courtès
Subject: Re: [PATCH 3/3] emacs: Add "Source" field to 'guix-info' buffers.
Date: Tue, 11 Nov 2014 00:29:48 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Alex Kost <address@hidden> skribis:

> Ludovic Courtès (2014-11-10 01:43 +0300) wrote:
>
>> Alex Kost <address@hidden> skribis:

[...]

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

OK.

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

OK, fair enough!

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

I think a single button is clearer than two buttons plus a label, but
that’s OK here since we can’t really do just one button.

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

There’s still the possibility that (1) the source is there, so no
“Download” button, (2) the source is GC’d, and (3) there’s still no
“Download” button and trying to access the source fails gracelessly.

That’s probably not very common in practice, and easily fixed by hitting
‘g’, so maybe it’s not worth worrying.  WDYT?

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

Sounds good!

> +(define (package-source-names package)
> +  "Return a list of source names (URLs) of the PACKAGE."
> +  (let ((source (package-source package)))
> +    (and (origin? source)
> +         (filter-map (lambda (uri)
> +                       (cond ((string? uri)
> +                              uri)
> +                             ((git-reference? uri)
> +                              (git-reference-url uri))
> +                             (else #f)))
> +                     (list-maybe (origin-uri source))))))

The #f case above just leads to degraded display, not breakage, right?
(I’m asking because of the other things beyond string? and
git-reference?.)

Thanks,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]