[racket-dev] proposal for moving to packages

At Tue, 21 May 2013 05:29:19 -0600, Jay McCarthy wrote:
> 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.

That's the right idea, but not precisely correct. If you `(require (for
syntax ...))' a module, then the module is still needed at run time,
because it might have a `(require (for-template ...))', and so on.

A modules referenced though `lazy-require' in a `for-syntax' import,
however, could conceivably be omitted. For example, a large part of the
Typed Racket compiler might be omitted as a run-time dependency for a
Typed Racket program. We're not quite to the place where that will work
out well, but I think we'll get there.

> Similarly, for building the documentation.

That's really the big one in the short run, I think. It's difficult to
have anything small and still have Racket-style documentation.


At Tue, 21 May 2013 08:10:02 -0700, Eric Dobson wrote:
> Why would you need to run raco setup if the source was already
> precompiled?

It's easy to underestimate the complexity of `raco setup'. Indeed, if
every `raco setup' started from scratch, it would be pretty easy.

Instead, `raco setup' has to perform an incremental computation based
on an inferred set of filesystem changes, where the computation to
incrementalize includes bytecode compilation, document rendering,
document database cross-referencing, path adjustments, and more --- and
it's all supposed to work in parallel, it's not supposed to leave
things in a bad state if it gets interrupted, it should recover from
most any state including bad states inadvertently created by novice
programmers, it's supposed to support shared non-writable parts and
user-specific writable parts, it's supposed to support PLTCOLLECTS and
PLTCOMPILEDROOTS, and it's supposed to have a dozen other properties
that I'm forgetting at the moment.

To answer the specific question, one reason you need to run `raco
setup' on a precompiled collection to fix up the documentation
cross-reference database and references, get libraries and launchers in
place, and perform whatever install-time actions the package wants.

Yes, we can make `raco setup' work with packages that contain both
source and binaries, and I guess I'll go work on that instead of other
directions.