[racket-dev] haskell's 'hell of a lot of libraries', planet

Basically, CPAN is a way of distributing and finding tarballs that
have Perl code it in. The CPAN tool installs these things into a
system or user directory of "collects". People have written Perl
modules that overload the module lookup to find and download new CPAN
packages if necessary.

If PLaneT worked the same way, it would "just" be a way of
distributing our .plt files. We'd have a more powerful planet tool to
deal with these. Instead, we make the syntactic difference YC
mentions.

--

If PLaneT didn't work this way, then when I have a file that reads
"(require ds)", it isn't meaningful without additional information
about what packages (& versions thereof) should be installed before
compiling and running it. One argument in favour of how PLaneT
currently works is that this additional information is "in the
language" (something I see as a design principle behind Racket)
because we instead write "(require (planet nintendo/ds))".

Thinking about the location of this additional information points to
me that we currently have only "internal" linking of packages. I can
imagine an "external" linkage where, for example, the nearest
"info.rkt" file specified what packages needed to be installed. [Perl
modules have something similar to that actually.]

Jay

On Tue, Jul 27, 2010 at 8:06 PM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> I looked at the message where you link and I didn't see how one would
> go about this.
>
> I guess the idea is that you'd eliminate the syntactic difference
> between a planet-located library and one in the distribution and then
> require on some external source to know where the package is located?
> Something like that? How would that work?
>
> Robby
>
> On Tue, Jul 27, 2010 at 8:17 PM, YC <yinso.chen at gmail.com> wrote:
>> IMHO planet works very well and shouldn't have issue to scale beyond a few
>> thousand packages if it ever gets to that point.  However, to get there I
>> believe planet first needs one major upgrade - it needs to become "location
>> transparent" - meaning that requiring modules in COLLECTS and PLANET look
>> exactly the same from code perspective.
>> With this change the invisible cultural divide between planet and core
>> distribution will disappear, and core team can tap into the work of module
>> developers, which in turn will help module developers feel more involved in
>> the community - the virtuous cycle can then be built to gain momentum to
>> increase the community.
>> I have discussed the issues in detail back in January in the
>> thread http://lists.racket-lang.org/users/archive/2010-January/037703.html -
>> and love to discuss further if others are interested.
>> Cheers,
>> yc
>>
>> On Tue, Jul 27, 2010 at 2:45 PM, Matthias Felleisen <matthias at ccs.neu.edu>
>> wrote:
>>>
>>> If this hasn't come up yet here, please do take a look at
>>>
>>>
>>>  http://donsbot.wordpress.com/2010/05/31/there-are-a-hell-of-a-lot-of-haskell-libraries-now-what-are-we-going-to-do-about-it/
>>>
>>> I am sure we will face this kind of problem one day and we might be able
>>> to prepare ourselves a bit.
>>> _________________________________________________
>>>  For list-related administrative tasks:
>>>  http://lists.racket-lang.org/listinfo/dev
>>
>>
>>
>>
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
>>
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev



-- 
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://teammccarthy.org/jay

"The glory of God is Intelligence" - D&C 93