how to distinguish public vs private (entry-point vs internal) systems
rpgoldman at sift.info
Wed Feb 6 15:26:52 UTC 2019
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
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.
>> On 06 Feb 2019, at 15:36, Robert Goldman <rpgoldman at 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
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the asdf-devel