[racket-dev] updated proposal for moving to packages

On Thu, Jun 6, 2013 at 9:23 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:

> Trying to characterize the milestones doesn't really seem to capture
> the potential danger at this point, though. If we can build installers
> that let users run DrRacket, then I think there's not so much that can
> go wrong in terms of delivering a release.
>
> There are some potential problems; for example, I think DrRacket's rule
> on when to compile packages in debugging mode needs a tweak. But that
> level of danger is different from, say, the dangers of re-implementing
> the snip, drawing, and GUI classes, where testing is more difficult.

I think there are other things that can go wrong that are harder to
test for: for example, the new system could fail to work with how some
linux distribution builds Racket, or the way packages are laid out
could conflict with some school's Windows file permission settings, or
the new way that JS is used to fix links in documentation could not
work on IE 6 (I hope we don't actually care if that happens).  But I
also don't think there's a way to find this out without trying.

> At Wed, 5 Jun 2013 22:42:12 -0400, Sam Tobin-Hochstadt wrote:
>> - I'm not entirely happy with the -doc/-lib/etc split, since it seems
>> to make everything more verbose and difficult to work with.  But I
>> haven't tried developing in that environment, so maybe it's not a big
>> deal.  I also worry that it makes our repository less approachable to
>> new people.
>
> I agree. One possibility is that few packages will be split so finely
> --- only ones where the difference in dependencies is large and there
> are clients for the low-dependency "-lib" package (in constrained
> environments? in settings with frequent rebuilds?). If we don't
> anticipate such clients, however, maybe we shouldn't try it at all.

Right now, the core of the Typed Racket implementation [1] would be
under two additional layers of directory structure, compared to the
current tree. This would be annoying, but not deal-breaking.

However, it occurs to me that splitting the `typed-racket` package
into the `typed-racket-lib` and `typed-racket-doc` packages, with a
`typed-racket` package that depended on them, would be a
backward-compatible change for the future.  Thus, I'd prefer to not
split `typed-racket`, and maybe not anything except the core
documentation, as a first cut.

[1] https://github.com/mflatt/racket/blob/pkg/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/tc-expr-unit.rkt
>
>> - We still don't have a ton of experience with the package system
>> itself -- it's designated as beta in the current release, and there
>> are very few packages with non-trivial dependencies. In contrast, the
>> core repository has a lot of dependencies. For example, how will we
>> deal with backwards-incompatible changes to the split itself, since
>> packages are intended to be permanently compatible?
>
> Yes. This is both a significant difference and an example of a point
> that's difficult to explore without the split. When we have a big core,
> lots of packages can have zero dependencies other than the implicit
> dependency on the core.

With this in mind, I'll mention (without suggesting that we do it)
another option: that we split into packages, but keep a much larger
core than your `pkg` tree currently does -- all of the stack including
DrRacket, for example.  Then we'd gain experience, but not with
portions that are quite as crucial.

> When we have a small core, then there should be
> practically no packages without explicit dependencies --- when a
> package's dependencies are specified accurately, at least.

Is it possible to enforce, either in the package system or in DrDr or
somewhere else, that dependencies are specified accurately?

Sam