I'm cringing at the sight of XML here.
(I almost through this post away when I read down and saw the work on
Corkscrew but I thought some of my ideas might still be valid).
What I'd like to see is something that execute *inside* Clojure,
adding necessary libraries the classpath in some way:
I would like to see idiomatic Clojure, not XML, something along the lines of:
(ns com.example.foo
(:use 'clojure.packages))
(packages
(:use [(clojure.contrib "1.0-alpha-3" test-is pprint)
(foo.mylib "2.0.3")]))
It seems to me that a packages library would be capable of locating
and downloading JARed Clojure code as needed; the (packages) macro
would store package dependencies and would be capable of identifying
conflicts and resolving transient dependencies.
There would need to be standard rules for how the Clojure JAR would be
named and located, in a Maven-like structure (i.e.
clojure/contrib/clojure.contrib-1.0-alpha-3.jar).
It seems to me that dependencies would just be a matter of the
execution of the (packages) macro in the loaded library.
It would also be interesting if the AOT compile process could expose
some form of hook such that dependency information could be captured
in a file (i.e., writes a META-INF/clojure-contrib.dep file that
contains overall dependencies for the module). This would allow a
relatively dumb tool, such as an Ant plugin, to proactively download
all necessary dependencies.
On Mon, Aug 3, 2009 at 2:16 PM, James Reeves<weavejes...@googlemail.com> wrote:
>
> Hi folks,
>
> I've been sketching out a design for a package manager for Clojure,
> similar to Rubygems. To the best of my knowledge, there's no real
> equivalent to this in Java-land.
>
> I'm looking for suggestions, criticisms, or for someone to tell me
> that Java already has a package manager that's better than the one I'm
> designing.
>
> The working name for this application is Clod. This name will probably
> be replaced with something a lot better.
>
> Clod is basically RESTful web service of dependency metadata. The
> client will open up http://clod.example.com and you might get an XML
> file like this:
>
> <repository name="example">
> <package name="Compojure" href="/packages/compojure"/>
> </repository>
>
> In many cases, the href attribute will be a relative URI, but it
> doesn't have to be. You could potentially create a repository that is
> distributed across many different servers. This could be very useful
> for maintaining a repository of third-party libraries. Instead of
> spending time ensuring your repository is up to date, just direct
> people to the websites of trusted third-parties.
>
> In fact, any element in Clod's XML can contain a href in place of a
> body. You could have a repository that just looked like this:
>
> <repository name="example" href="http://other-location.example.com"/>
>
> Or you could place your entire repository in one XML file. One of the
> nice things about this design is that if you want to put up a
> repository on your website, you could just upload a single XML file.
>
> However, for larger repositories, you'll likely want to split your
> repository into pieces. For instance, first you could have a page full
> of packages:
>
> <repository name="example">
> <package name="Compojure" href="/packages/compojure"/>
> </repository>
>
> Then for each package, you'd have a list of versions:
>
> <repository name="example">
> <package name="Compojure">
> <version name="0.2" href="/packages/compojure/0.2" latest="true"/>
> <version name="0.1" href="/packages/compojure/0.1"/>
> </package>
> </repository>
>
> And in each version, the full set of metadata:
>
> <repository name="example">
> <package name="Compojure">
> <version name="0.2">
> <author>
> <name>James Reeves</name>
> <email>jree...@weavejester.com</email>
> </author>
> <description>
> Web framework for Clojure.
> </description>
> <parents>
> <version name="0.1" href="/packages/compojure/0.1"/>
> </parents>
> <files>
> <file href="/packages/compojure/0.1/compojure.jar">
> <sha1>96dbe80bf4d897e08858eafdfa5ccab1de1886b8</sha1>
> </file>
> </files>
> </version>
> </package>
> </repository>
>
> I've decided to take a page from Git and allow there to be,
> potentially, multiple parent versions. This allows for the possibility
> of branch versions that merge together at a later date.
>
> Currently, there isn't much more to the protocol beyond this. Things
> like virtual packages, a more efficient search - all things I'm not
> too worried about at the moment. For the first iteration of this
> package manager, it'll only have to deal with a small number of
> packages, and I wanted a package manager that didn't necessarily need
> any dedicated server software to run.
>
> If you actually wanted a repository with thousands of packages, then
> you might actually need some complex software to manage all that data.
> But at this stage in Clojure's life, we're more likely going to have
> lots of little repositories with a few pieces of useful software on.
> Clod (or whatever it's name will eventually be) is created for that
> ecosystem, but designed to expand into something rather more
> sophisticated when the need arises.
>
> - James
> >
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
