how to distinguish public vs private (entry-point vs internal) systems

[Robert Goldman]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20190206/b515360b/attachment.html>