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

True, but in this case, the code that is doing that reading knows what
the package was and could give a good error message.

Jay

On Thu, Jun 13, 2013 at 9:13 PM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> 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
>
>



-- 
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