[racket-dev] Planet 2 Beta Release

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.

Robby

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!