[prev in list] [next in list] [prev in thread] [next in thread]
List: python-catalog-sig
Subject: Re: [Catalog-sig] [Distutils] PyPI - Evolve our own or reuse
From: "Arve Knudsen" <arve.knudsen () gmail ! com>
Date: 2007-08-17 10:47:21
Message-ID: a0d6258d0708170347r7da61aahc978d695824f7d85 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Very glad to hear you're interested in my system Bj=F8rn.
On 8/16/07, Bj=F8rn Stabell <bjorn@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 / Flexne=
t
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, an=
d
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 strengt=
h
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 ca=
n
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
[Attachment #5 (text/html)]
Very glad to hear you're interested in my system Bjørn.<br><br><div><span \
class="gmail_quote">On 8/16/07, <b class="gmail_sendername">Bjørn Stabell</b> <<a \
href="mailto:bjorn@exoweb.net">bjorn@exoweb.net</a>> wrote: </span><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">On Aug 15, 2007, at 21:34, Arve Knudsen wrote:<br>> \
These are some interesting points you are making. I have in fact <br>> been \
developing a general software deployment system, Conduit, in<br>> Python for some \
time, that is capable of supporting several major<br>> platforms (at the moment: \
Linux, Windows and OS X). It's not <br>> reached any widespread use, but we \
(at the Simula Research<br>> Laboratory) are using it to \
distribute software to students<br>> attending some courses at the \
university of Oslo. Right now we are<br>> in the middle of preparing for the \
semester start, which is next week. <br>><br>> The system is designed to be \
general, both with regard to the<br>> target platform and the deployable software. \
I've solved the<br>> distribution problem by constructing an XML-RPC Web \
service, that <br>> serves information about software projects in RDF (based on \
the<br>> DOAP format). This distribution service is general and \
independent<br>> of the installation system, which acts as a client of the latter. \
<br>><br>> If this sounds interesting to you I'd love if you checked it \
out<br>> and gave me some feedback. It is an experimental project, and as<br>> \
such we are definitely interested in ideas/help from others. <br><br>Hi \
Arve,<br><br>That's an interesting coincidence! :)<br><br>Without turning it into \
a big research project, it would be<br>interesting to hear what you (honestly) \
thought were the strengths<br>and weaknesses of Conduit compared to, say, \
deb/rpm/ports/emerge, <br>whichever you have experience with. I did \
download and look at<br>Conduit, but haven't tried it yet.</blockquote><div><br>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).<br> <br>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. <br><br>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. <br><br>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.). <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid \
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">There are so many \
ways to take this, and so many "strategic"<br>decisions that I'd hope \
people on the list could help out with. <br><br>Personally I think it would be great \
if we had a strong Python-based<br>central package system, perhaps based on \
Conduit. I'm pretty sure<br>Conduit would have to have the client and \
server-side components even <br>more clearly separated, though, and the interface \
between them open<br>and clearly defined (which I think it is, but it would have to \
be<br>discussed).</blockquote><div><br>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. <br></div><br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">I see Conduit (and PyPI) supports DOAP, and looking \
around I also<br>found <a href="http://python.codezoo.com/"> \
http://python.codezoo.com/</a> by O'Reilly; it also seems to have a<br>few good \
ideas, for example voting and some quality control (although<br>that's a very \
difficult decision, I guess).</blockquote><div><br>CodeZoo is a very interesting \
initiative. I let myself inspire in part by CodeZoo when I started designing Conduit, \
but mostly by SWED ( <a href="http://swed.org.uk">http://swed.org.uk</a>) 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).<br></div><br></div>Arve<br>
_______________________________________________
Catalog-SIG mailing list
Catalog-SIG@python.org
http://mail.python.org/mailman/listinfo/catalog-sig
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic