[racket] raco pkg install with zipfile

At Sat, 31 May 2014 11:09:31 -0400, Tony Garnock-Jones wrote:
> Hi Matthew, all,
> 
> On 2014-05-31 2:24 AM, Matthew Flatt wrote:
> > Unfortunately, there's a mismatch between the way GitHub packages a
> > ".zip" and the way `raco pkg install` uses it. The GitHub-generated
> > ".zip" file has an extra directory layer relative to the layout that
> > `raco pkg install` expects.
> 
> My mistake. I had been led to believe by [1] that the extra directory
> layer was somehow being magically dealt with for single-collection
> packages, and that therefore it was weird that multi-collection packages
> weren't working the same way.
> 
> Having just tried the instructions from [1] with a single-collection
> package, it actually doesn't work in that case either :-)

Aha! I, too, had the impression recently that this should work, but I
even more recently went through the experience of it not working.

Along the same lines, I have been confused after trying to zip a whole
directory (from outside the directory) and use the zip archive as a
package in place of the directory.


> Could raco go hunting in the tarball/directory/whatever for an info.rkt
> file that could orient it to the intended layout of the package?

I think it might work to have the following rule: if an archive
contains a single directory, then that archived directory's content is
used as the package, instead of the archive's content.

The one-directory rule would be a backward-incompatible change, but it
would only break a single-collection package that provides only a
sub-collection --- which I think is an unlikely combination. So, maybe
we could get away with the change.

The special directory rule would be a little trouble for unpackers to
deal with. Packing tools could take the regular approach of always
introducing a directory layer. (That change would make me happy,
because I don't like ".zip" or ".tgz" files that contain multiple
top-level items.) That wouldn't work packages that might be used by
v6.0.1 and earlier, though.