Ludovic Courtès (2014-11-11 02:29 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2014-11-10 01:43 +0300) wrote:

[...]

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

What can be done is: if a source is not in the store after pressing a
“Show” button, a user may be asked whether he wants to download it or
not.  I think it should be less confusing (the modified patch is
attached).  WDYT?

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

Do you mean a user deleted the source (with "guix gc") when a “package
info” buffer was displayed?  Sure such cases are not (and I think cannot
be) handled.  It's the same as if:

1) a user has a list of installed packages,

2) installs another package somewhere outside (e.g., in a shell with
"guix package -i"),

3) and wonders why the list is not up-to-date.

Of course it is not up-to-date!  He needs to revert a buffer after that.

[...]

>> +(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?.)

Yes, there _would_ be just "Source: –", but it will not happen because
there are no other things beyond a string URL and a git-reference URL.
So the source field will be empty only for packages with a false source
(like ‘mit-scheme’ or bootstrap packages).  Sources for all other
packages will be displayed.  You may check it by evaluating the
following:

(setcdr (assq 'output guix-list-column-format)
        '((name 20 t)
          (version 10 t)
          (output 9 t)
          (installed 12 t)
          (source 30 t)))

then "M-x guix-all-available-packages" and sort by the "Source" column.