Common Lisp style: multiple packages in same repo

[Faré]

I've seen flat namespaces and one-package-per-file and everything
in-between and beyond. All style can be done well or be done poorly.
What matters most is that namespaces must be curated to be livable.
Having someone responsible to maintain it, make it good, make it
consistent, keep it good, fix the bugs, improve the interfaces, etc. —
That's the important and hard part.

That said, I admit I've grown to like the approach of ASDF and LIL, of
one-package-per-file internally (also each file a system, as for LIL),
plus special package files that (automatically) import and reexport
all symbols in a directory. This style imposes a somewhat onerous
discipline, but in exchange you have a powerful framework to keep you
code well-organized: each file by construction can only refer to
symbols from files that it depends on, you have think of your
dependencies clearly. Any forward reference requires special
provisions. Without this discipline, ASDF could not have grown up from
the 4516 line mess that ASDF had become as of 2.6, to the
well-organized 13525 line robust and portable software that it is as
of 3.3.2.9. It does so much more under the hood, and is portable to so
many more platforms, yet at the same time the code is so much more
readable, and the underlying algorithm, while much more elaborate, is
also much more understandable. One of the few things that survives of
my work at ITA :-(

As for LIL, it also uses packages for punning: there are distinct but
related symbols stateful:insert pure:insert classy:insert and
posh:insert for inserting a key / value pair in a map in all
combinations of stateful interface-passing-style, pure
interface-passing-style, classic imperative object oriented style, and
purely functional object oriented style — with macros that can
automatically wrap one into the others. That's incredibly powerful and
liberating: being able to use parametric polymorphism to bootstrap
elaborate pure functional data structures like Haskell typeclasses,
then exporting classic imperative object-oriented hierarchies for
users who don't want to know.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Trillions of fossils can't be wrong!


On Sat, Aug 25, 2018 at 8:32 PM Scott McKay <swmckay at gmail.com> wrote:
>
> +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 <kentilton at 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 <daniel at 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/