On Mon, Mar 26, 2018 at 3:11 PM, Neil Van Dyke <n...@neilvandyke.org> wrote: > 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;
I assume that people do it because they see the team that produces DrRacket, the GUI, etc doing it. > 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 It is necessary to make "minimal" packages and to have a "minimal" install. I think the main use case is that documentation is likely to include a picture, which will be generated by plot or one of the many drawing systems, and then including documentations means that a headless server now needs all the GUI tools. > 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)? My opinion is that many existing packages can be divided up in the way you suggest. > 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). My original hope was that we could have tools to automatically produce test-less/doc-less/etc-less editions of packages from a single source, but figuring out what to include/not-include is pretty hard in Racket and it turns out that making these sorts of separating decisions by the author is pretty much exactly what the package system provides for. Jay -- -=[ Jay McCarthy http://jeapostrophe.github.io ]=- -=[ Associate Professor PLT @ CS @ UMass Lowell ]=- -=[ Moses 1:33: And worlds without number have I created; ]=- -- 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.
