[racket-dev] Other PLaneT 2 questions

From: Jay McCarthy (jay.mccarthy at gmail.com)
Date: Tue Dec 4 21:19:29 EST 2012

On Tue, Dec 4, 2012 at 5:22 PM, Danny Yoo <dyoo at hashcollision.org> wrote:
> * Will there be a procedure for package revocation?  For example, if I put
> something up, I may want to take it down, either because it should be
> renamed, or it's bitrotted code.

You can already rename it.

Deleting it is very easy (for me, I just delete a file), I could expose this.

> * Will there be an easy way to pull a full list of packages programmatically
> from the central repositories?  One of the things I want is the ability to
> provide separate views of the packages, say to overlay something like
> ratings, or comments.  So if the central repository web site can't provide
> this, still make it possible for people to pull the relevant content
> programmatically.

Yes, there will be. But, if you want something on the site, I'd rather
you just send patches to the server. That's why it is public and easy
to try running locally.

> * Will there be a consistent convention for declaring a package's test
> cases?  In Perl's CPAN, for example, we know how to run the test cases for
> any CPAN'ed package.  They even trust it well enough that it's usually part
> of the installation process, so that if the test cases fail, the
> installation fails reliably.  It would be nice if Racket packages supported
> the same convention.

No. In Racket you can just do "raco test ." and all the tests in the
whole package will be run, so there's no reason for this sort of
thing.

Even more no, the various levels of trust are mainly about tests. In
the highest level of trust, DrDr will run all the tests on every
Racket push.

> * I think I remember seeing comments about having the documentation
> available before installing.  What's the status of this?

Obviously it would be trivial to just add a link to the site to
developer-maintained docs, but I don't think this will be the best
solution. Packages generally won't contained compiled content, like
documentation, so it won't by default be on the normal package source
link.

The future plans discusses these issues. There are other issues, like
the fact that packages can have arbitrary numbers of Scribble files,
so there's not just one link, in any case.

My plan is for DrDr-built packages to have their documentation kept
and published at a link.

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.