Re: Prothon and a CPAN-like archive

On Wednesday 23 June 2004 07:40 am, gyrof wrote:
> Paul Prescod wrote:
> > I think that you are right on all counts. It is VERY important and
> > could be a key differentiator.
> >
> > But I don't know that there is much that an be done this early in the
> > process. It is hard to know how the language could anticipate the
> > existence of a source repository...
> >
> > Maybe there is some tie in with import hooks.
> >
> >  http://python.active-venture.com/whatsnew/section-pep302.html
> >
> >  Paul Prescod
>
> Hi Paul,
> Good points.
>
> Can anyone with some in-depth knowledge of Perl explain what
> language changes (if any) were implemented to facilitate CPAN? If
> no language changes were needed, what other components (utilities,
> databases, etc.) were necessary or helpful?
>

The CPAN module helps tremendously, as does having everyone follow a
standard for assembling and deploying modules.

> If language changes are not needed, perhaps Prothon modules that
> evolve could begin to adhere to some standards in terms of
> whatever metadata is needed for
> archival/retrieval/versioning/conflict resolution/dependencies/...
>
> In the abstract, it should be useful to reflect on the Perl
> experience as well as the Python struggle with this issue. What
> worked? What didn't? What were the lessons learned?
>

Module versioning is a must. There are times when you want to run and older
and a newer version of a module side-by-side.

CPAN has no built-in test phase or a way to say "This is production quality,
and that is not." That leads to people wondering which modules to use when.

CPAN tries to handle things like mod_perl, which probably don't really
belong in CPAN, but in their own CPAN sort of thing that is seperate.

It is difficult to set up your own module distribution system to complement
CPAN's. Yum (part of Fedora) allows this and it is quite easy and useful.
We need something like that.

The namespace gets polluted, and there is no really good way to clean it up.
We need to think about this.

Finally, sometimes you are faced with a choice between several different but
good options. Which one is the standard? No one can tell except those with
lots of experience.

I've always thought that a zero-install method would be the way to go. We
would reference modules by a URL, and if it was installed, we would just
use our cached copy. If it wasn't, we would fetch it from the URL and
install it right away. We can build in security and reliability as well as
"pre-fetching" modules. I think we can assume nowadays that all computers
are connected to some kind of network.

--
Jonathan M. Gardner
Mass Mail Systems Developer, Amazon.com
[email protected]