[plt-scheme] the *issue* of the planet module system

YC,

I think most of us PLT developers would like to be able to integrate
Planet and the collections, such that PLT products could import Planet
packages, and be exported as Planet packages.  This has been a desire
of ours for some time.  However, this would take a significant
rearrangement of our infrastructure.  We would also have to clarify
the issues of intellectual property for Planet packages.  It will take
time and resources we simply have not yet had a chance to invest.  I
don't think there is a plan on the horizon right now, but we do agree
with you that there's a lot of untapped potential.  Hopefully we'll
have a chance to take greater advantage of it soon.

Carl Eastlund

On Thu, Jan 14, 2010 at 6:22 PM, YC <yinso.chen at gmail.com> wrote:
> Hi all -
>
> I have been a happy planet user for quite a while.  AFAICT, it is the best
> (if not, at least one of the best) module/repository technology available
> today.
>
> But lately an issue comes to my mind and it's bugging me. Okay, the
> repository is fine - it is the way that the module system distinguishes
> between collects and planet.  Specifically, the planet modules are second
> class citizens.
>
> The collects modules today take precedences over planet modules, since they
> are included in the distribution with a simpler syntax.  While this makes
> sense technically, the implications are:
>
> Modules from planet will not be packaged into the distribution
> In order for the planet package to make it into the distribution, it will
> have to be *ported*
> collects modules cannot take advantage of code on planet
> collects modules cannot easily "retire" onto planet
>
> This reduces code reusability, since if the core team wants to include a
> package for distribution, they will have to port it, instead of just using
> it via planet. And unless we are invited to join the core team, our planet
> modules are not likely to make it there.
>
> In CPAN, if the Perl distributors find a module useful, they can include it
> with the language without fuss.  That means all CPAN modules are candidates
> for eventual inclusion with no additional work on the module developer's
> part, as long as others find their work usefully enough for
> inclusion.  Many Perl modules started on CPAN this way and were eventually
> included into the default distribution.
>
> But for PLT you cannot do it without causing work (unless you want your
> install to depend on live internet connection).  Say if Jay wants to reuse
> some web modules from planet, he would have to "port" it, or rewrite it in
> order to include it into collects.
>
> In other words, the location "non-transparency" that module system has
> erects a wall separating the PLT core team from the planet module
> developers.  This impacts reusability both ways - core devs cannot take
> advantage of planet modules verbatim, and planet modules will not be
> included for distribution.
>
> The reverse is also true, collects modules will not have the option to be
> retired to planet if they are not found to be useful, since they weren't
> designed to live on planet.
>
> So - assuming reusability and community growth are important, and that the
> core team does not want to port all useful planet modules in order to use
> them, I would love to hear comments on this topic, whether I am just blowing
> smoke or that it has merit, comments, etc.
>
> Thanks,
> yc