<div dir="ltr"><div><div>Thanks for the info. </div>Binaries may still be good when one wants to install a package only for a single purpose. </div> </div><div class="gmail_extra"> <div class="gmail_quote"> On Tue, Sep 24, 2013 at 12:50 AM, Matthew Flatt <<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Although packages are not currently distributed in binary form, you can install built packages (as available from a snapshot site) in binary mode by supplying the `--binary' flag to `raco pkg install'. For example, if you start with a Minimal Racket build from <a href="http://www.cs.utah.edu/plt/snapshots/" target="_blank">http://www.cs.utah.edu/plt/snapshots/</a> then install it on Mac OS X (64-bit), it starts with a footprint of about 30 MB. Using bin/raco pkg install -i --binary images installs about 40 packages to bring the total footprint to about 70 MB. In contrast, using bin/raco pkg install -i images installs about 95 packages to bring the total footprint to about 260 MB. Fewer packages are installed in binary mode because build dependencies are pruned from each package as it is converted (on download) from "built" to "binary". The "binary" versus "built" distinction doesn't automatically exclude documentation. The 40-ish packages installed for "images" includes "images-doc", because the "images" package is meant to imply both "images-lib" and "images-doc". Little other documentation is installed, however, because other documentation is mostly needed only to build the "images" documentation. The smallest installation with the "images" libraries is bin/raco pkg install -i --binary images-lib which installs about 30 packages to bring the total footprint to about 55 MB. Then again, sticking with built mode as bin/raco pkg install -i images-lib installs the same 30-ish packages with a footprint of 65 MB, which illustrates that the savings from `--binary' are almost all from reducing dependencies (and not about omitting source). So, `--binary` is available and can help, but it's an indirect way of reducing dependencies. Improved support for generating, installing, and depending on "-lib" variants might be better in the long run --- but I think we don't know how to do that, yet. <div class="HOEnZb"><div class="h5"> At Mon, 16 Sep 2013 09:04:49 -0600, Jay McCarthy wrote: > Hi Laurent, > > I think that the solution to this are "binary" builds.... versions of > a package that only have the bytecode and documentation. > > We're a bit behind on binary builds, because when they were discussed > for the main repository [1] they were rejected. I hope to be able to > still provide them for ring-0 packages through the results of DrDr > running tests (and thus compiling) on those packages, but it's in the > future. > > The result would be that when you installed a package in "binary" > form, you would only get the "deps" and not the "build-deps". (And > you'd probably get those in binary form too.) > > Jay > > 1. <a href="http://www.mail-archive.com/dev@racket-lang.org/msg08879.html" target="_blank">http://www.mail-archive.com/dev@racket-lang.org/msg08879.html</a> > > On Mon, Sep 16, 2013 at 2:32 AM, Laurent <<a href="mailto:laurent.orseau@gmail.com">laurent.orseau@gmail.com</a>> wrote: > > Hi, > > > > (this is not a complain, just an inquiry) > > > > While installing Racket on a small server, I wanted to avoid installing gui > > and doc related libraries. > > The minimal install was great! > > > > Then I wanted to install a package of my own (the aptly named "bazaar"), > > which requires "images" and other gui libs (which I actually would not use > > on the server), among other things, but no doc > > > > But the "images" package draws racket-doc and gui-doc dependencies, which in > > turn draws practically all of Racket. And it then takes a much longer time > > for `raco setup` to do its job that I had hoped for. > > > > Certainly, this can be resolved by splitting "images" and "bazaar" into lib, > > gui and docs packages, but I foresee another problem: > > It's difficult to enforce such a split for third-party libraries, as it puts > > the burden on the user. > > And the first package like that to be installed will again draw all of > > Racket dependencies. > > > > This is probably not a trivial matter, but what can be done about this? > > > > My dream would be that gui and doc dependencies are never triggered, without > > preventing the packages I actually use to be downloaded, but I don't know > > how this could actually be ensured without a good amount of magic. > > > > Merely preventing downloads does not sound like a good option though. > > > > I bet you've already discussed this far and wide, so are there any plans? > > > > Laurent > > > > _________________________ > > Racket Developers list: > > <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> > > > > > > -- > Jay McCarthy <<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>> > Assistant Professor / Brigham Young University > <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a> > > "The glory of God is Intelligence" - D&C 93 > _________________________ > Racket Developers list: > <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> </div></div></blockquote></div> </div>