Philip McGrath wrote on 03/26/2018 02:15 PM:
"foo"/"foo-lib"/"foo-doc"/"foo-test" package groups, which seem to be a prominent part how the Racket package system is used in practice.
Is a convention of breaking up code packages into separate lib/doc/test packages a good thing, or is it usually done because (theories):
1. people saw it mentioned in package system docs, and/or saw an example of it, and assumed it was a recommended practice;
2. it is to mitigate actual space/time problems (e.g., "I don't want to build docs when I deploy", "I don't want to compile anything on my little router") that could better be handled by the right simple tools support, while keeping the packages and package model clean and simple; or
3. there is perceived pressure from large and monolithic packages (e.g., a small use ends up working with lots of linearly-scaled bytes of package, and the documentation portion of those bytes is wrongly blamed, rather than the sheer amount of code stuff), but some of those monolithic packages might better be decomposed into smaller and more flexible topical packages (rather than lib/doc/test)?
Just checking that this is on the best practical path, since, in some regards, we aren't stuck legacy like some are. The Racket package system was redone from scratch rather recently, and not saddled with 25 years of engineering debt like some other packages systems for distros and languages. We also have the advantage that code in Racket packages can use the flexibility of the language for modularity purposes that otherwise might put more burden on a package system. We still have opportunity to have the package system be fairly clean and simple, and to save the rare bulk/complexity for high-value features (e.g., versioning, stripping).
-- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
