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