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

[Robert Goldman]

I think the approach of disabling operate is not a good solution to this 
problem because, for example (this is one I have actually encountered), 
one might have multiple test systems that one wishes to test separately.

E.g.,
"Foo/input-test"
"Foo/processing-test"
... and so on.

So I think it's better to handle this in a way that focuses on 
Quicklisp, and indexing, rather than attempting to change the core 
functions of ASDF.  It's just as easy to create a system class that 
simply says "I am a system that Quicklisp should not build."

Unfortunately, there has been enough bad blood between Xach and some 
members of the ASDF-devel community that this discussion won't be 
reaching him.  Jim, Hugo, either of you want to try to be a conduit?


Best,
R

On 6 Feb 2019, at 10:52, Hugo Ishimaru wrote:

> Hi,
>
> when I read your post, I instantly came up with the system that may
> not be the target of OPERATE like
> ;; foo.asd
> ;; 
> https://gist.github.com/privet-kitty/84350b73d528533ac8e19e5bba6aa333
> (defpackage :foo.asdf
>   (:use :cl :asdf :uiop)
>   (:export #:hideable-system))
> (in-package :foo.asdf)
>
> (eval-when (:compile-toplevel :load-toplevel :execute)
>   (defclass hideable-system (system)
>     ((private :initform nil :initarg :private :reader private-p))
>     (:documentation "If PRIVATE is true, ASDF signals an error when
> one tries to OPERATE this system."))
>
>   (defmethod operate :around (operation (component hideable-system)
> &key &allow-other-keys)
>     (if (private-p component)
>         (error "Private system ~S cannot be directly operated."
> (component-name component))
>         (call-next-method))))
>
> (defsystem "foo"
>   :license "public domain"
>   :depends-on ("foo/private")
>   :components ((:file "main")))
>
> (defsystem "foo/private"
>   :pathname "private"
>   :class "FOO.ASDF:HIDEABLE-SYSTEM"
>   :private t
>   :components ((:file "package")))
>
> Here FOO/PRIVATE cannot be OPERATEd (but can be PERFORMed and then
> loaded, compiled, tested etc. via FOO). It seems to work at least
> superficially, though ASDF Best Practices states:
>
>> You SHOULD NOT define methods on asdf:operate --- most of the time 
>> it's totally the wrong thing
>> because users would not be "operating" on your system, but on their 
>> system that depends on it.
>> Instead you SHOULD define methods on asdf:perform, 
>> asdf:component-depends-on, etc.
> https://gitlab.common-lisp.net/asdf/asdf/blob/master/doc/best_practices.md
>
> Anyway, I don't have a sufficient knowledge on ASDF's internal.


Robert P. Goldman
Research Fellow
Smart Information Flow Technologies (d/b/a SIFT, LLC)

319 N. First Ave., Suite 400
Minneapolis, MN 55401

Voice:	(612) 326-3934
Email:    rpgoldman at SIFT.net