long-description

Robert Goldman rpgoldman at sift.info
Thu Feb 21 16:22:14 UTC 2019


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'm ok with this, but not so enthusiastic that I'll do it myself.  I'd 
be happy to accept a pull request.

I'd also like some discussion about how this change would come into 
being.  It's not especially backward compatible, but it should not cause 
breakage -- people using older versions of ASDF would just see a 
pathname in the unlikely event that they tried to retrieve the 
`long-description`.

Can anyone else think of any unexpected consequences?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20190221/881cf12b/attachment.html>


More information about the asdf-devel mailing list