<div dir="ltr">great, thanks, that was quick!<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 16, 2013 at 6:34 PM, Robby Findler <span dir="ltr"><<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">In the meantime, the images pkg is now broken up and images-lib depends only on draw-lib (and some unstable stuff), no longer on the full gui library or the docs.<span class="HOEnZb"><font color="#888888"><div>
<br></div><div>Robby</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Sep 16, 2013 at 11:24 AM, Laurent <span dir="ltr"><<a href="mailto:laurent.orseau@gmail.com" target="_blank">laurent.orseau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div>Sounds good!<br><br></div>I think as long as it's possible to somehow choose between byte-code and source-code packages/distributions, there should not be too much to worry about. My server would be very happy with byte-code packages, and my desktop with a full source-code Racket.<span><font color="#888888"><br>
<br></font></span></div><span><font color="#888888">Laurent</font></span><div><div><br><div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 16, 2013 at 5:04 PM, Jay McCarthy <span dir="ltr"><<a href="mailto:jay.mccarthy@gmail.com" target="_blank">jay.mccarthy@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Laurent,<br>
<br>
I think that the solution to this are "binary" builds.... versions of<br>
a package that only have the bytecode and documentation.<br>
<br>
We're a bit behind on binary builds, because when they were discussed<br>
for the main repository [1] they were rejected. I hope to be able to<br>
still provide them for ring-0 packages through the results of DrDr<br>
running tests (and thus compiling) on those packages, but it's in the<br>
future.<br>
<br>
The result would be that when you installed a package in "binary"<br>
form, you would only get the "deps" and not the "build-deps". (And<br>
you'd probably get those in binary form too.)<br>
<br>
Jay<br>
<br>
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><br>
<div><div><br>
On Mon, Sep 16, 2013 at 2:32 AM, Laurent <<a href="mailto:laurent.orseau@gmail.com" target="_blank">laurent.orseau@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> (this is not a complain, just an inquiry)<br>
><br>
> While installing Racket on a small server, I wanted to avoid installing gui<br>
> and doc related libraries.<br>
> The minimal install was great!<br>
><br>
> Then I wanted to install a package of my own (the aptly named "bazaar"),<br>
> which requires "images" and other gui libs (which I actually would not use<br>
> on the server), among other things, but no doc<br>
><br>
> But the "images" package draws racket-doc and gui-doc dependencies, which in<br>
> turn draws practically all of Racket. And it then takes a much longer time<br>
> for `raco setup` to do its job that I had hoped for.<br>
><br>
> Certainly, this can be resolved by splitting "images" and "bazaar" into lib,<br>
> gui and docs packages, but I foresee another problem:<br>
> It's difficult to enforce such a split for third-party libraries, as it puts<br>
> the burden on the user.<br>
> And the first package like that to be installed will again draw all of<br>
> Racket dependencies.<br>
><br>
> This is probably not a trivial matter, but what can be done about this?<br>
><br>
> My dream would be that gui and doc dependencies are never triggered, without<br>
> preventing the packages I actually use to be downloaded, but I don't know<br>
> how this could actually be ensured without a good amount of magic.<br>
><br>
> Merely preventing downloads does not sound like a good option though.<br>
><br>
> I bet you've already discussed this far and wide, so are there any plans?<br>
><br>
> Laurent<br>
><br>
</div></div>> _________________________<br>
> Racket Developers list:<br>
> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br>
><br>
<span><font color="#888888"><br>
<br>
<br>
--<br>
Jay McCarthy <<a href="mailto:jay@cs.byu.edu" target="_blank">jay@cs.byu.edu</a>><br>
Assistant Professor / Brigham Young University<br>
<a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br>
<br>
"The glory of God is Intelligence" - D&C 93<br>
</font></span></blockquote></div><br></div></div></div></div></div></div></div>
<br>_________________________<br>
Racket Developers list:<br>
<a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>