+1 I think we did OK in CLIM: an API package, and an internal package to implement in.
--Scott > On Aug 25, 2018, at 7:53 PM, Ken Tilton <kentil...@gmail.com> wrote: > > Packages are massively overrated. This is not Java where every frickin source > file is a namespace. There is a certain obsessive compulsiveness about > packages that does nothing but slow developers down. Well, right, they are a > palliative for the OCD disease. But it *is* a disease, so that does not count. > > What part of agile do we not understand? Fences, boxes, categories, types all > invented for their own sake let us bask in our taxonomicity while getting no > code written, and god help the sucker who tries to use our OCD mess forever > battling package issues. > > Stop. Wrong way. Go back. > >> On Tue, Aug 21, 2018 at 6:36 PM, Daniel Pezely <dan...@pezely.com> wrote: >> I posted this to Stack Overflow but was hoping for more input. >> https://stackoverflow.com/questions/51638864/common-lisp-style-multiple-packages-in-same-repo >> >> >> May I get recommendations or links to representative code repositories with >> good style for multiple related Common Lisp packages, please? >> >> For instance, consider a high-level workflow library with accompanying >> lower-level API, each in its own CL package but same git repo due to >> synchronized releases. >> >> Each system (*.asd file) isolates tests and may be invoked using: >> >> (asdf:test-system foo :force t) >> >> Separate systems may be built via make, which definitely helps isolate SBCL >> code-coverage reports. >> >> Some users of the library may only want to load the lower-level API. For >> simplifying dependencies for those using higher-level API, it seems >> best to keep everything bundled in one repo. Any revision to one library >> would likely require updating all for the same release. >> >> I currently have a single directory tree with a subdirectory for each CL >> package. There's a top-level Makefile plus one in each subdirectory that the >> library maintain would use. The top-level also contains symbolic links for >> .asd files pointing into relevant subdirectories. (It's a library deeply >> dependent upon POSIX calls via uiop-posix, so it's only applicable on an OS >> with sym-links.) >> >> This seems to be an issue at large considering issue #1 for Quicklisp-docs >> [0]. >> >> Found nothing relevant in Google's CL style guide [1], State of the Common >> Lisp Ecosystem, 2015 [2], Edi's CL Recipes [3] or Lisp-lang [4]. Browsing >> repos seem to have quite a mix of styles. >> >> [0] https://github.com/rudolfochrist/quicklisp-docs/issues/1 >> [1] https://google.github.io/styleguide/lispguide.xml >> [2] >> https://web.archive.org/web/20160305061250/http://eudoxia.me/article/common-lisp-sotu-2015/ >> [3] http://weitz.de/cl-recipes/ >> [4] http://lisp-lang.org/learn/writing-libraries but see also their section >> on Continuous Integration >> Repo to be fixed: https://gitlab.com/dpezely/cl-mmap >> (commit a23bd88d of 2018-07-14; release will be tagged when fixed) >> >> Thanks, >> -Daniel >> > > > > -- > Kenneth Tilton > http://tiltontec.com/
