Greg Trzeciak wrote on 01/31/2017 01:24 PM:
Speaking of packages - there seems to be a trend recently in racket packages to create separate packages for main, lib, doc, test, etc. This causes an artificial inflation in available packages and IMHO may cause some confusion for newcomers as instead of finding eg. "PackageX" we now get the following instead:
I agree with Greg that this looks like people are going out of their way to make clutter. I don't think that ever should have been encouraged.
I think the "lightweight languages" way to do this is to do this in most cases is to distribute a single package that includes the implementation+tests+scribble, not split up the package. The normal case should be to include everything in a package as a developer or library user, including modifying it. Packages only rarely are big, and hardly anyone is working on tiny microcontrollers or other tight deployments.
For the benefit of the tightwad people, packages could optionally include metadata about any docs and tests that can be stripped -- anything nonessential to "run-only" the package. This metadata could be used by either the installation tools or by a package file transformer tool that people can run themselves. (And, eventually, these tests and documentation might normally be linguistic constructs anyway, embedded within the code, not something in their own files that can be maintained in a separate package from the implementation.) The package catalog still only lists the one canonical package, though.
A rare special case would be things like demos that pull in big dependencies that are often not wanted (e.g., neural nets library that has a GUI demo). That demo you might put in a separate package, for the same reasons you might put a big neural nets GUI visualizer tool in a separate package from your neural nets library, even if it wasn't a demo -- because it has big different dependencies, and the main functionality of the package is very often used without it. (Of course, not all demos have to be in a separate package. The `charterm` demo has a small implementation, and doesn't pull in big additional dependencies, so I just threw it into the main package, and documented it that way: "http://www.neilvandyke.org/racket/charterm/#%28part._.Demo%29";.)
Another rare special case is when you have big "test data" that you can't trim down and you really think should be distributed with the package. Offhand, I can think of only one example I'm aware of this in Racket, though I assume there are some situations I don't know about, and it does occur with real-world research data. When it's research data, this might also involve open scientific data archiving/sharing efforts, and you might want to look at those efforts in your field. Of course, big real-world data might not be that good as software engineering regression tests anyway, even if you ran the data through "as a test" or as a practical application of your code for your thesis, so maybe that data doesn't belong in the package anyway.
Again, I think the normal case is one package that includes all implementation+tests+scribbles.
-- 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.
