[racket-dev] Planet 2 Beta Release

On Thu, Nov 8, 2012 at 8:16 AM, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
> Now that the 5.3.1 release is finished, I've just pushed the beta release of
> Planet 2 to the Racket core.

Here, as promised, more detailed but small comments.  I have one
larger design issue, which I want to write up in a separate mail.

* I think the places you use 'PLT' in the documentation should be
replace with 'Racket maintainers' -- PLT is a research group with lots
of overlap with the Racket maintainers.

* I think tying to GitHub is a mistake -- the system should work for
for arbitrary Git repositories.  Having a short syntax for github is
great, though.  Additionally, we should support fixing a checksum for
a package.  The npm docs have a similar list of things that can be
installed here: https://npmjs.org/doc/install.html

* I think we should drop the `.plt` archive format entirely.

* It would be nice to have a command-line way of publishing a package
to a name service.

* I think use 'dont-' in command line arguments is potentially
confusing, and the 'no-' prefix is more common in other software.

* It would be nice to have fewer special files.  For example,
`MANIFEST` could be abolished by just fetching the whole content of
the directory.  Checksums could be included in the `METADATA` file.

* Similarly, the names of the special files could avoid ALL-CAPS, and
I'd go with the name 'package' rather than `metadata`.

* I think 'update' with no arguments shouldn't do a global operation;
use `-a/--all` for that, otherwise it's easy (say in scripts) to
accidentally trigger the global behavior.

* In section 3.1, you should have 'git push -u origin master'.

* We really need valid SSL certificates for any user-facing sites.
StartSSL gives them away for free: http://www.startssl.com/

* I thought the conclusion of a recent discussion on dev@ was that
tests, typed, etc sub-collections *are* preferred.

* Can the Planet1 compatibility also have a version-less translation
for the latest version, so that `jaymccarthy/opencl/module` could keep
working?

* I think the auto-installing module resolver mentioned in "Short
Term" is a bad idea -- it's already really easy to install packages
with this system, and auto-installation just introduces possibility
for headaches.

--
sam th
samth at ccs.neu.edu