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

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