On 6 Feb 2019, at 9:02, Jim Newton wrote:
I’m both asking how they should be named, and how to advertise them
for programmatic consumption.
For example, and automatic testing program such as that included in
quicklisp, should not try to stand-alone
load systems which are not designed to work stand-alone. We have to
work around this by artificially
making all systems “work” in standalone enough to fool quicklisp.
Can you explain the quicklisp constraint? How does it find all systems?
One simple expedient for *this* quicklisp issue -- if I understand it
correctly -- would be to have a `test-op` default `perform` 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
`test-op` no-op method that emits no warning (because the system is
intended not to be testable).
quickref is another tool which tries to publish documentation
extracted from packages, but quickref would
like to skip packages which are not part of the public API, such as
test case packages which may require
other non-public testing frameworks.
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 `package` object so that it can
hold a slot that can designate it as `internal` or `external`. Quicker
could provide a trivial system that would export this package extension.
I think it would be useful for other documentation systems, as well.
It would be nice if asdf had some declarative way of specifying which
systems are intended as entry points.
That would also avoid different people relying on non-standard naming
conventions to encode declarative
information.
The trivial solution here would be to create a class inheriting from
`asdf:system` that would be something like `internal-system`. Harder
would be getting people to adopt it.
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.
Best,
Robert
On 06 Feb 2019, at 15:36, Robert Goldman <rpgold...@sift.info> wrote:
On 6 Feb 2019, at 2:22, Jim Newton wrote:
When creating an lisp application I usually have one (or several)
what I call top-level asdf systems
which advertise the public interface to the application, and I may
have several internal systems
which are used but not intended for public use.
What is the convention with asdf to distinguish entry-point systems
from internal/private
systems?
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.
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.
