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

Hugo Ishimaru privet.kitty99 at
Wed Feb 6 16:52:33 UTC 2019


when I read your post, I instantly came up with the system that may
not be the target of OPERATE like
;; foo.asd
(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))

(defsystem "foo"
  :license "public domain"
  :depends-on ("foo/private")
  :components ((:file "main")))

(defsystem "foo/private"
  :pathname "private"
  :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.

Anyway, I don't have a sufficient knowledge on ASDF's internal.

More information about the asdf-devel mailing list