<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 6 Feb 2019, at 9:02, Jim Newton wrote:</p>

</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">I’m both asking how they should be named, and how to advertise them for programmatic consumption.<br>
For example, and automatic testing program such as that included in quicklisp, should not try to stand-alone<br>
load systems which are not designed to work stand-alone.   We have to work around this by artificially<br>
making all systems “work” in standalone enough to fool quicklisp.</p>
</blockquote></div>
<div style="white-space:normal">

<p dir="auto">Can you explain the quicklisp constraint?  How does it find all systems?</p>

<p dir="auto">One simple expedient for <em>this</em> quicklisp issue -- if I understand it correctly -- would be to have a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">test-op</code> default <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">perform</code> method for all systems that simply succeeds.  It should probably by default issue a warning that no "real" test method exists, and that warning should have a particular type so that it can be muffled by quicklisp.  Probably also we should allow the programmer of the original system to make a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">test-op</code> no-op method that emits no warning (because the system is intended not to be testable).</p>

</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">quickref is another tool which tries to publish documentation extracted from packages, but quickref would<br>
like to skip packages which are not part of the public API, such as test case packages which may require<br>
other non-public testing frameworks.</p>
</blockquote></div>
<div style="white-space:normal">

<p dir="auto">I'm not sure that ASDF can do anything about this one -- packages are not an artifact that it really understands or takes responsibility for.  Perhaps it would be better to extend the <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">package</code> object so that it can hold a slot that can designate it as <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">internal</code> or <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">external</code>.  Quicker could provide a trivial system that would export this package extension.  I think it would be useful for other documentation systems, as well.</p>

</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">It would be nice if asdf had some declarative way of specifying which systems are intended as entry points.<br>
That would also avoid different people relying on non-standard naming conventions to encode declarative<br>
information.</p>
</blockquote></div>
<div style="white-space:normal">

<p dir="auto">The trivial solution here would be to create a class inheriting from <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">asdf:system</code> that would be something like <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">internal-system</code>.  Harder would be getting people to adopt it.</p>

<p dir="auto">But if there's interest, I could try to make one or, given the limited amount of time I have to work on ASDF these days, I would be happy to accept a pull request.</p>

<p dir="auto">Best,<br>
Robert</p>

</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">On 06 Feb 2019, at 15:36, Robert Goldman <rpgoldman@sift.info> wrote:<br>
<br>
On 6 Feb 2019, at 2:22, Jim Newton wrote:<br>
<br>
When creating an lisp application I usually have one (or several) what I call top-level asdf systems<br>
which advertise the public interface to the application, and I may have several internal systems<br>
which are used but not intended for public use.<br>
<br>
What is the convention with asdf to distinguish entry-point systems from internal/private<br>
systems?<br>
<br>
I generally try to use either Faré's "slashy" systems (like "shop2/common") in my work. When I can, it's even better to use a :module which isn't visible at all.<br>
<br>
I think what you are really asking is "how should I name a system that the user should never load directly?" I don't have a great answer to this question.<br>
</p>
</blockquote></blockquote></div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>