[racket-dev] Planet 2 Beta Release

From: Jay McCarthy (jay.mccarthy at gmail.com)
Date: Thu Nov 8 15:56:06 EST 2012

On Thu, Nov 8, 2012 at 1:48 PM, Eli Barzilay <eli at barzilay.org> wrote:
> 20 minutes ago, Jay McCarthy wrote:
>> > * 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
>>
>> Github automatically generates zip/tgz files. Planet 2 knows nothing
>> about Github other than this and the URL structure of their site to
>> get them and the checksums.
>
> This is something that many (probably all) git places do -- and even
> the gitweb script that we're using on git.racket-lang.org knows how to
> do.  (See the "zip" and "tar.gz" links.)  In any case, since this is
> just a URL format thing, it should be easy to put it in some place
> that could be easily extended for other places, and possibly
> pluggable.

I'm fine with that... but I don't have the bandwidth to develop it for
anything I don't use.

>
>> If you'd like to implement general git support, I think that would
>> be great, but it is more work than I have time to do. I can point
>> you in the right direction.
>
> If you have a "git" command, then it's a simple matter of using "git
> archive".  There's some robust git looking in the repo-time-stamp
> collection that could be lifted up for this.
>

Yes I was going to that first, but (a) I didn't want to rely on the
git command and (b) github doesn't support "git archive".

>> > * I think we should drop the `.plt` archive format entirely.
>>
>> It is the default because Racket can create it and unarchive it
>> natively.  If someone implements a native Racket zipper/unzipper,
>> that would be great. My understanding is that this is on Eli's todo
>> list and when it is done, it would be great to change Planet 2's
>> default.
>
> How about requiring a format for now, to avoid changing the default
> later?

I'll do that.

>
>> The checksum can't be in the metadata because the metadata is in the
>> archive, but you need to be able to get the checksum without getting
>> the archive.
>
> (Is the checksum only needed for detecting updates?  If so, then why
> not use just the timestamp?)

The checksum is just a string, with no interpretation, you could use a
timestamp as yours. In the case of github though, I can easily get the
checksum but not a timestamp.

>> > * Similarly, the names of the special files could avoid ALL-CAPS,
>> > and I'd go with the name 'package' rather than `metadata`.
>>
>> I have no preference about this shed color. If others feel strongly,
>> it can change.
>
> I do.  It would be better IMO to look at existing packagers and reuse
> some of their conventions.  (I know that at least the chrome packages
> have similar things, and I liked their design.)

I based the convention off CPAN with its META.yml file.

>> > * In section 3.1, you should have 'git push -u origin master'.
>>
>> This is directly from the Github docs:
>> https://help.github.com/articles/create-a-repo
>
> Using -u is much better.  The reason it is not in the github page is
> possibly that they're aiming at ancient git versions that didn't have
> it.  (IIRC, when we migrated to git this option was new, and should be
> safe to assume that everyone has it now...)  (Also, I'm not sure how
> well they maintain those help pages -- they had a few more educational
> projects since we migrated, and recently there's something even more
> ambitious.)
>

Changed.

>> > * I thought the conclusion of a recent discussion on dev@ was that
>> > tests, typed, etc sub-collections *are* preferred.
>>
>> I think I missed this conversation.  I don't understand the
>> conclusion given that we don't want to always distribute tests, for
>> example.
>
> It should be possible to distribute the separate parts regardless of
> where they are.  The thing is that with a single directory management
> of code is much easier.  Eventually, many of the collections in the
> current tree should move out into their own repositories.

In any case, I've missed it and will make the change to the
recommendations, although personally I like having separate
directories like tests because it doesn't clutter my main code
directory.

Jay


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

Posted on the dev mailing list.