long-description

[Robert Goldman]

The more we discuss this, the more I think it's a solution in search of 
a problem. Just using the standard ASDF file-inclusion capabilities 
(that Faré shows in his email) seems sufficient to me, and also keeps 
a nice uniformity -- if you want the long description, you ask for it, 
and you know it's a string.  It also imposes a cost in complexity with 
only a conjectural benefit (who would consume the new pathname 
designations, **and** which library authors and maintainers would supply 
it?).  If users are offended by the excess number of bytes, the macro 
facility is available.

I prefer not to give the yak any more facial hair! 😉

On 25 Feb 2019, at 10:43, Raymond Toy wrote:

> On Thu, Feb 21, 2019 at 8:23 AM Robert Goldman <rpgoldman at sift.info> 
> wrote:
>
>> On 20 Feb 2019, at 22:14, Faré wrote:
>>
>> I've seen the pattern of using
>> :long-description
>> #.(uiop:read-file-string
>> (uiop:subpathname *load-pathname* "README.md"))
>> spread among CL libraries.
>>
>> I see it only as a waste of kilobytes of data (quadrupled on 32-bit
>> unicode lisps such as SBCL).
>>
>> I'm told it's because Quickdocs likes it this way.
>>
>> Since there is not (yet?) any type enforcement on the value of that
>> field, can we instead agree for an alternate format, wherein the 
>> field
>> would instead contain the pathname of the long-description file,
>> relative to the (asdf:system-source-directory) ? Thus you'd use:
>> :long-description #p"README.md"
>> And Quickdocs and other documentation tools would do the right thing 
>> from
>> there.
>>
>> Let me see if I understand clearly:
>>
>>    1.
>>
>>    As before, if you put a string in here, you get the string itself 
>> as
>>    the value of :long-description.
>>    2.
>>
>>    If there is a pathname literal in here you get the contents of 
>> that
>>    file as the value of :long-description.
>>
>> Is this correct?
>>
>> I find option 2 kind of strange.  What if I really just wanted the
> pathname as the description?  Having it produce the contents of the 
> file
> seems really odd.  I think it's up to the developer/user to decide 
> whether
> to display the file or not.
>
> My 2 cents, as someone who doesn't really use asdf all that much 
> (because
> the projects are pretty much done and working.)
> -- 
> Ray


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20190225/69f8c1b9/attachment.html>