[Catalog-sig] [Distutils] PyPI - Evolve our own or reuse existing package systems?

[Arve Knudsen]

Very glad to hear you're interested in my system Bjørn.

On 8/16/07, Bjørn Stabell <bjorn at exoweb.net> wrote:
>
> On Aug 15, 2007, at 21:34, Arve Knudsen wrote:
> > These are some interesting points you are making. I have in fact
> > been developing a general software deployment system, Conduit, in
> > Python for some time, that is capable of supporting several major
> > platforms (at the moment: Linux, Windows and OS X). It's not
> > reached any widespread use, but we (at the Simula Research
> > Laboratory) are using it to distribute  software to students
> > attending some courses at the university of Oslo. Right now we are
> > in the middle of preparing for the semester start, which is next week.
> >
> > The system is designed to be general, both with regard to the
> > target platform and the deployable software. I've solved the
> > distribution problem by constructing an XML-RPC Web service, that
> > serves information about software projects in RDF (based on the
> > DOAP format). This distribution service is general and independent
> > of the installation system, which acts as a client of the latter.
> >
> > If this sounds interesting to you I'd love if you checked it out
> > and gave me some feedback. It is an experimental project, and as
> > such we are definitely interested in ideas/help from others.
>
> Hi Arve,
>
> That's an interesting coincidence! :)
>
> Without turning it into a big research project, it would be
> interesting to hear what you (honestly) thought were the strengths
> and weaknesses of Conduit compared to, say, deb/rpm/ports/emerge,
> whichever you have experience with.  I did download and look at
> Conduit, but haven't tried it yet.


I would say the main difference lies in how Conduit is designed to be a
completely general solution for distributing software and deploying it on
user's systems, with as loose coupling as possible. You could say that what
I am trying to achieve is closer to MacroVision's Install Anywhere / Flexnet
Connect than to monolithic package managers such as APT, Emerge etc. The
former offers a complete solution to independent providers for letting them
deliver software and maintain it (with updates) over time, while the latter
is a tightly integrated service which is even used to implement operating
systems (e.g. Debian, Gentoo).

Conduit tries to offer the best of both worlds by building a central
software portal from independent project representations. The idea is that
software providers maintain their own profile within the portal service, and
associate with this a number of projects which are described in RDF (an
extension of the DOAP vocabulary). The portal service accumulates these
data, and expose them to installation agents via a public XML-RPC API.

I've written a framework for Conduit agents that currently supports
installing on Linux, Windows (XP/Vista) and OS X. I find it a great strength
to be able to offer a common installation system for all three platforms,
but the weakness is that generally it doesn't integrate as well with the
operating systems as native installers do.

On Windows at least I plan to piggy-back on the native installation service
(Windows Installer), to achieve better integration without having to
reinvent the wheel. On Linux it is worse since there is no well-defined
native installation service, but instead a bunch of different packaging
systems which overlap with my own deployment model (specification of
dependencies etc.).

There are so many ways to take this, and so many "strategic"
> decisions that I'd hope people on the list could help out with.
>
> Personally I think it would be great if we had a strong Python-based
> central package system, perhaps based on Conduit.  I'm pretty sure
> Conduit would have to have the client and server-side components even
> more clearly separated, though, and the interface between them open
> and clearly defined (which I think it is, but it would have to be
> discussed).


The client and server components should be clearly separated as-is, but the
server API should definitely be reviewed and properly defined.
Conduit-specific support exists on the server as extensions (namespace
"conduit") of the RDF vocabulary.

I see Conduit (and PyPI) supports DOAP, and looking around I also
> found http://python.codezoo.com/ by O'Reilly; it also seems to have a
> few good ideas, for example voting and some quality control (although
> that's a very difficult decision, I guess).


CodeZoo is a very interesting initiative. I let myself inspire in part by
CodeZoo when I started designing Conduit, but mostly by SWED (
http://swed.org.uk) which has a similar model of accumulating decentralized
information in RDF for centralized access (via a Web interface). I would
actually like Conduit's distribution service to evolve into something with
similar functionality to CodeZoo. A rich Web interface for navigating the
catalog of software would be awesome (an alternative to sourceforge?). I've
also pondered the possibility of user profiles in the portal so that one can
keep preferences centrally, for instance as a way to define personal
"installation sets" (e.g., after installing a new Linux, restore your
previous installations).

Arve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/catalog-sig/attachments/20070817/69e3cfbd/attachment.htm