Re: CPAN-type thing: specifications, wishes, thoughts?

[Noah Lavine]

Hello all,

I'm afraid this email is coming much later in the planning process
than it should, and quite possibly we won't be able to do any of this
for SoC, and that's fine with me. But I was thinking about what we
could do that would be a "killer feature" for Guile's CPAN - something
that isn't already done by apt-get, dorodango, and every other package
manager. One answer is that having a big collection of Guile packages
*is* a killer feature, but we could have an apt repository of those if
we wanted one.

I think the answer is that the killer feature for a large repository
of packages is having the ability to painlessly bundle a piece of
software you've been writing and all of its dependencies in one
easy-to-install thing for users. After all, it's easy when you're
developing on your own machine to download a bunch of packages and use
them to do whatever you need to do, but if you then want to send that
to other people, you've got to collect the source code (or at least
.go files) for all of them, put them in a folder, make sure the
load-path will work out, and then most importantly, do all of that
again every time a new version of one of your dependencies comes out.
I think the feature that is missing is the ability to say "take my
software and package it so that its only external dependency is
POSIX", or something similar.

The implementation of such a thing isn't especially deep, but I bet
there will be a lot of little things that need to be done just right
for it to work. I think this could be a part of a package manager that
also does the other things Paul was listing.

How does this idea sound?

Noah

On Tue, Apr 12, 2011 at 11:01 PM, Paul Raccuglia <address@hidden> wrote:
> Hi. Since the idea of creating something like CPAN is something folks
> wants, I figure it would be good to collect as many thoughts and
> information as possible in one place.
>
> (I'd also appreciate links to relevant threads)
>
> My thoughts, specifically, were for the client to be fairly similar in
> function to apt-get. (from the user's perspective)
> The core commands would be:
>
> INSTALL package_name   -- queries a server (set in configuration
> files), gets an absolute link to the package, and a list of
> dependencies. Downloads the package, and then any dependencies, and
> takes care of unpacking, verifying, compiling, storing, etc. anything
> that needs to be done. The package would have to have meta-data
> attached in some fashion.
>
> REMOVE package_name -- just has to remove all the relevant files, and
> clean up any references to the package in the storage system. May want
> to check dependencies and alert the user.
>
> UPDATE [package_name] -- could be called to check all packages (by not
> specifying a package name) or to update a specific package. Warn the
> user of any dependencies that could be broken.
>
> My thought was that the package manager could, itself, be a package
> (but, hopefully, one that would be included by default). I wouldn't
> imagine that the current code base would need to be modified a whole
> lot.
>
> I was thinking that most of this project could be written in Guile.
> Does that make sense?
>
> Some thoughts I heard were:
> using stowfs to handle storing the packages intelligently
> use dorodango to handle most of the acquisition
>
>
> For the server design:
> I was envisioning a website to navigate packages (like
> http://packages.debian.org/stable/). My thought is to do everything
> over HTTP (seems like that would work well with Dorodango). Doesn't
> seem like a hugely complicated issue?
>
> Questions about the server:
> How would the central repository be maintained? Give trusted
> developers the ability to make changes to their personal packages at
> will?
> How will packages be nominated / selected for inclusion?
>
>
> That's all I can think of, right now. I'm sure there's more but I want
> to start a discussion. Thanks,
> Paul R
>
>