[racket-dev] experience using the `pkg` branch

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Thu Jun 13 23:13:29 EDT 2013

WRT to the stacktrace below, I guess that if the info.rkt file had been in
a suggestively named directory, e.g.,

/var/tmp/pkg13711534991371153499937/future-visualizer/info.rkt

(assuming that the package's name was future-visualizer) that might have
been a useful clue.

Robby



On Thu, Jun 13, 2013 at 9:56 PM, Jay McCarthy <jay.mccarthy at gmail.com>wrote:

> On Thu, Jun 13, 2013 at 3:56 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>
> wrote:
> > As part of my experiment in creating a different split of the
> > repository into packages, I spent some time working with the new setup
> > for building Racket, and cut myself on many of it's rough edges.  Some
> > of these are about the package system in general, and some are about
> > the new repository and build infrastructure.
> >
> > * When there's an installation error, it's really hard to tell what
> > state you're in, or what you should do to fix it.  Usually, the
> > package manager just says that it's already installed.
> >
> > This is a general issue in the package system, and it's easily the
> > most significant problem I encountered. The package system decides
> > that something is installed very early, and many errors are possible
> > after that. If the package didn't build, or it's dependencies didn't
> > build, or any of many other things happened, the package system thinks
> > everything is ok.
>
> The package system says something is installed when the files are in
> place and the link is made. From some perspective, that's its job.
> Knowing whether 'raco setup' will succeed after those are in place
> isn't really possible beforehand and I don't think the idea of 'run
> raco setup and uninstall if it fails' is robust against the sorts of
> realistic and innocuous problems that raco setup can report. Maybe you
> could be more specific about what error you saw and what you wish had
> happened.
>
> > * The error message when you look for a missing collection is really
> > long if you have a lot of packages installed
> >
> > * Using parallel make, ie `make -j 8` doesn't work from the new
> > top-level Makefile.
> >
> > * Even though unix systems don't use them, the extra libraries are
> > downloaded and packaged up on unix platforms while building.
> >
> > * When installing a package with a long chain of dependencies, this
> > message gets printed a lot:
> >
> > The following packages are listed as dependencies, but are not
> > currently installed,
> > so they will be automatically installed:
> >     at-exp-lib syntax-color
> > The following packages are listed as dependencies, but are not
> > currently installed,
> > so they will be automatically installed:
> >     parser-tools
> >
> > and so on ...
> >
> > We should just collect all the packages to be installed and print them
> > all at once (and perhaps prompt, the way `apt-get` does).
>
> Since package dependencies are in the package and not otherwise
> available, the manager is asking for permission to do a download.
> After doing the download, it can then look at the dependencies and see
> if there more. 'apt-get', etc have more monolithic repository
> structures than our package system, so they can analyze everything
> locally and compute the transitive closure. Furthermore, 'raco pkg' is
> prompting you, but you have it set on "auto" (the default) so it's
> equivalent to 'yes | apt-get'
>
> > * I think it's possible to confuse the local catalog by moving
> > directories around in the `pkg` directory.
> >
> > * `make local-catalog` is not incremental -- it always re-downloads
> > and re-packs the external libraries.
> >
> > * Sometimes, errors can be hard to trace to a particular package.  For
> > example, this one was because there was a mistake in the
> > future-visualizer package info.rkt file.  But I had to go groveling in
> > /var/tmp/ to figure that out.
> >
> > /var/tmp/pkg13711534991371153499937/info.rkt::212: read: expected a
> closing '"'
> >   context...:
> >
>  /home/samth/tmp/pkg-racket/racket/lib/collects/syntax/module-reader.rkt:176:17:
> > body
> >
>  /home/samth/tmp/pkg-racket/racket/lib/collects/syntax/module-reader.rkt:173:2:
> > wrap-internal
> >    lang:read
> >
>  /home/samth/tmp/pkg-racket/racket/lib/collects/setup/getinfo.rkt:50:8:
> temp32
> >    /home/samth/tmp/pkg-racket/racket/lib/collects/setup/getinfo.rkt:37:0:
> > get-info/full/ext
> >    /home/samth/tmp/pkg-racket/racket/lib/collects/setup/getinfo.rkt:33:0
> >    /home/samth/tmp/pkg-racket/racket/lib/collects/pkg/lib.rkt:1274:0:
> > pkg-single-collection85
>
> Are there other examples? This stack trace is useful to just put a
> with-handlers at the right spot.
>
> > Other errors are also hard to track down. In general, it would be very
> > helpful to catch setup errors and report them based on the package
> > being installed and/or the collection being set up.
> >
> > Sam
> > _________________________
> >   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
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130613/94a66b16/attachment-0001.html>

Posted on the dev mailing list.