[Scheme-reports] practical matters - CSAN Alex Shinn (23 Aug 2011 02:31 UTC)
|
Re: practical matters - CSAN
Arthur A. Gleckler
(23 Aug 2011 02:59 UTC)
|
Re: [Scheme-reports] practical matters - CSAN
John Cowan
(23 Aug 2011 04:57 UTC)
|
Re: [Scheme-reports] practical matters - CSAN
Aubrey Jaffer
(23 Aug 2011 21:55 UTC)
|
Re: [Scheme-reports] practical matters - CSAN
Alex Shinn
(24 Aug 2011 00:09 UTC)
|
Re: [Scheme-reports] practical matters - CSAN
John Cowan
(24 Aug 2011 01:17 UTC)
|
Re: [Scheme-reports] practical matters - CSAN
Alex Shinn
(24 Aug 2011 01:58 UTC)
|
Re: [Scheme-reports] practical matters - CSAN
Aubrey Jaffer
(27 Aug 2011 02:58 UTC)
|
Re: [Scheme-reports] practical matters - CSAN
John Cowan
(28 Aug 2011 04:41 UTC)
|
Re: [Scheme-reports] practical matters - CSAN
Aubrey Jaffer
(29 Aug 2011 16:19 UTC)
|
Re: [Scheme-reports] practical matters - CSAN
Aaron W. Hsu
(29 Aug 2011 16:31 UTC)
|
Re: [Scheme-reports] practical matters - CSAN
Aubrey Jaffer
(07 Sep 2011 00:19 UTC)
|
There have been multiple attempts[1][2] at creating a shared repository of Scheme code analogous to Perl's CPAN, but none have gained much traction. On the other hand, implementation-specific repositories[3][4][5] have been very successful. As an effort to unify these (and seriously, we're a small community, we need all the unification we can get), I would like to set up a CSAN-like system based on the R7RS module system, so that any Scheme that supports R7RS modules can easily share code. I will be drafting a design document soon and appreciate any feedback that can be offered, but in the meantime the current plans are: * Search, fetch, install and test R7RS modules and programs. R6RS and other module systems can be supported later, possibly with some degree of auto-translation. * Decentralized server. The initial version you install will point to a single default repo URL which will contain an sexp list mapping module names to package URLs, along with a checksum and other meta-data. Users will be free to edit the list of repo URLs themselves, and later versions will allow repos to link to other repos. Bridges to existing package repos may also be provided later. [Note this framework makes the whole issue of mapping modules to paths moot.] * Authentication throughout, of module publishers and repos themselves, with user-adjustable trust levels. Modules use pet names (no central registry), but you set your trust on a per-publisher/pet-name basis. So if you set your trust such that Alice's modules under (wonderland ...) are safe, they're installed without confirmation. Confirmation in untrusted cases should also provide explicit warnings about conflicts and suspicious pet names. Later, summaries of the "capabilities" used by a module (such as file I/O, networking, eval, etc.) can be provided. * A rating system. CPAN is full of 80% (and worse) solutions, and multiple implementations of the same functionality. This is a crucial feature. -- Alex [1] http://snow.iro.umontreal.ca/ [2] http://synthcode.com/scheme/common-scheme/doc/common-scheme.html [3] http://wiki.call-cc.org/chicken-projects/egg-index-4.html [4] http://planet.plt-scheme.org/ [5] http://www.makelinux.net/man/1/G/gauche-package _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports