On 2018-08-22 02:10 PM, Pascal Bourguignon wrote:
On 22 Aug 2018, at 00:36, Daniel Pezely <dan...@pezely.com
<mailto: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? [...]
You’re asking about different things.
[...]
In short: it depends!
Thanks, Pascal!
Yes, these are different-- yet intertwined as integral parts of a whole.
Regarding git repos: in this case, it's just one person. The source
code is small enough that it would be maintained by one person for
foreseeable future, including potential forks supplying missing features
that might be apparent to those familiar with conventional mmap use cases.
Regarding asdf systems versus packages: the hooks for invoking the test
harness (Prove), launches via asdf mechanisms. For practical purposes,
these are tightly coupled here.
Regarding files: as much as I admire the Smalltalk model, my pragmatic
side tips the scales in favour of being confined to conventional CL
tools and approach, hence: asdf, uiop-posix, Prove and accommodating
possible future inclusion by Quicklisp.
Oddly enough, I was expecting to drink from a fire hose of highly
opinionated yet qualified CL advice.
By way of comparison, I just returned from Rust Conf in Portland,
Oregon/US, last week and was reminded that their `cargo` package manager
has "workspaces" [1]. It synchronizes dependencies of multiple packages
within a common directory tree. That satisfies criteria described in
the original post, apart from being for a different language of course.
(Unfortunately, I don't have time to contribute a Lispy equivalent as
the most recent start-up company didn't quite go as intended... but I
digress.)
[1]
https://doc.rust-lang.org/book/second-edition/ch14-03-cargo-workspaces.html
Thanks again for all your recommendations and insights!
-Daniel
