[racket-dev] Planet 2 Beta Release

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Fri Nov 30 13:38:43 EST 2012

Yes, I think we're roughly on the same page. Printing is a bad idea
when installing, but logging seems fine and that is how drracket can
detect it should update the GUI to let people know that something is
being installed. And a command-line flag (that perhaps translates to
some setting on the namespace that is derived from a parameter) can
determine if installing packages is allowed or not.

I think all this is doable and I think we can get something that keeps
the "kiss" principle and make things "just work" in common situations
without sacrificing security or whathaveyou.


On Fri, Nov 30, 2012 at 10:38 AM, Eli Barzilay <eli at barzilay.org> wrote:
> Just now, Robby Findler wrote:
>> In DrR, it isn't looking at the log that tells you this, you get a
>> special bar appearing in the window. You don't have to do any extra
>> clicks or anything like that.
> (Yeah, take that as a generalized version of my "see the log"...)
>> That said, I don't mind if, when someone runs some planet2 code in
>> racket, outside drracket, that it raises an error saying "you need
>> to pass the --slow-me-down-but-automatically-download-missing-
>> packages flag, or just run this program in drracket".
> WRT the automatic download + install -- while it's obviously possible
> to do that, I think that because of such things it's generally bad to
> actually make "real code" depend on it.
> Here's what I mean: if you assume that there should always be some
> visible indication of a package being installed, there is not going to
> be some magical require that would always work silently, and that can
> interfere with actually running the code.  For example, you do some
>   (require (download-and-install-from-somewhere))
> and it might produce some output or it might not -- and the code that
> uses this might break if there's unexpected output.
> But such a functionality is obviously useful -- so how about including
> it only for interactive purposes, which means that you can use it in
> your blogged code since you know that the extra output is not
> interfering with your code.  If OTOH you post some script for people
> to run, then you don't use that and instead tell people that they
> should install the other needed package, and later just pack your own
> code as a package.
> ----
> This might lead to an interesting direction.  Since it's not boring,
> it might not be a good idea, but still I think that it looks
> promising...
> Imagine that there was some meta syntax for required packages (I'll
> use emacs-like hackish-isms):
>   #lang racket
>   ;; *** Requires: some-package ***
>   ... code ...
> This idea can be taken further to add more package-like features,
> eventually like
>   #lang racket
>   ;; *** Package: name-for-this-code-as-a-package ***
>   ;; *** Requires: some-package ***
>   ... code ...
> which can eventually make it possible to treat a single file as a
> package.
> The nice thing that should be obvious now is that there's no need for
> such hacks, since that require line is serving the same purpose.
> Except that to really make it possible to do this effectively, you
> need to be able to know the package information separately for the
> code -- and submodules look like a perfect way to do that.  Just
> replace the hacks with something like:
>   #lang racket
>   (module pkg planet/pinfo   ; for "package info" or whatever
>     (define package name-for-this-code-as-a-package)
>     (requires some-package)
>     (requires some-other-package and-another))
>   ... code ...
> Or drop the define for the shorter case.  And since this is still
> pretty verbose, it might be abstracted away in some macro.  (But I
> don't remember the dependency issues with such things, so it might not
> be doable as is.)
> I think that with something like that you can get everything that you
> want.  A plain run in drr can do the same thing when it sees that
> there's a package inforation.  Toplevel requires in the racket input
> can do the same, but just requiring this file from another will not do
> it which means that you can also use it this way without worrying
> about interfering with real runs.  And you can also have some new
> command like "raco pkg install-whatever-is-needed-for some-file.rkt"
> which would be like doing the toplevel require thing.
> --
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                     http://barzilay.org/                   Maze is Life!

Posted on the dev mailing list.