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 <rpgold...@sift.info>
pathname as the description? Having it produce the contents of the
seems really odd. I think it's up to the developer/user to decide
On 20 Feb 2019, at 22:14, Faré wrote:
I've seen the pattern of using
(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
would instead contain the pathname of the long-description file,
relative to the (asdf:system-source-directory) ? Thus you'd use:
And Quickdocs and other documentation tools would do the right thing
Let me see if I understand clearly:
As before, if you put a string in here, you get the string itself
the value of :long-description.
If there is a pathname literal in here you get the contents of
file as the value of :long-description.
Is this correct?
I find option 2 kind of strange. What if I really just wanted the
to display the file or not.
My 2 cents, as someone who doesn't really use asdf all that much
the projects are pretty much done and working.)