[racket-dev] proposal for moving to packages

On Tue, May 21, 2013 at 4:29 AM, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
> On Mon, May 20, 2013 at 10:05 PM, Eric Dobson <eric.n.dobson at gmail.com> wrote:
>> I'm not sure I follow on why binary packages make it easier to reduce
>> dependencies between packages, or why binary packages offer faster
>> installs.
>>
>> I'm guessing that binary packages prevent cyclic dependencies between
>> packages, but it seems like there are many other options that still
>> get this side effect. Such as explicit checks when building the
>> package.
>
> If you have the source, then you need all the phase >= 1 dependencies,
> but if you just have the binary then you only need the phase = 0 deps.
> Similarly, for building the documentation.

Like Philippe said a viewable source doesn't require this, only source
that can be compiled. Whether or not we want to support that I don't
know, but it seems like it should be possible.


>
>> For faster installs, the only benefit I see of binary packages over
>> precompiled source packages is a small savings in size which doesn't
>> seem like it would amount to much of the install time.
>
> In my tree, I have 20M of compiled code and 13M of source. I like the
> idea of a reduction of about 50% in size of downloads.

I'm not sure if something on the order of 10M is something to worry
about optimizing, that takes like 5-6 seconds to download on a 15Mbit
connection. And a minute on a much slower connection.
>
> However, the faster install point is really about the fact that users
> won't need to run "raco setup" and do the compilation/documentation
> build once they do the download of the source.

Why would you need to run raco setup if the source was already
precompiled? Also how well does the source compress compared to
compiled code?

>
> Jay
>
>> Can someone explain the claims for binary packages?
>>
>> On Mon, May 20, 2013 at 8:57 PM, Jon Zeppieri <zeppieri at gmail.com> wrote:
>>> On Mon, May 20, 2013 at 10:04 PM, Neil Van Dyke <neil at neilvandyke.org> wrote:
>>>> [snip]
>>>>
>>>> Example: Imagine I'm in the middle of writing a Racket program and am
>>>> wondering about characteristics of some kind of I/O port in Racket.  With
>>>> transparent source accessibility, I can just click on an identifier in my
>>>> program in DrRacket to start browsing the implementation.  Maybe I see a
>>>> possible improvement, or seeing the source pre-empts yet another email list
>>>> question that otherwise only Matthew could answer, or I feel empowered to go
>>>> add a new feature.  If the source is not as accessible, then I'm more likely
>>>> to be a mere naive user of the tools, rather than to understand the tools
>>>> and help improve them.
>>>>
>>>
>>> +inf.0
>>>
>>> Though the easiest way to make the source available is just to keep it
>>> in the distribution. I'll be sad to see it go.
>>>
>>> -Jon
>>> _________________________
>>>   Racket Developers list:
>>>   http://lists.racket-lang.org/dev
>> _________________________
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev
>
>
>
> --
> Jay McCarthy <jay at cs.byu.edu>
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
>
> "The glory of God is Intelligence" - D&C 93