Re: Package manager proposal
2009/8/6 James Reeves weavejes...@googlemail.com:
On Aug 6, 8:31 pm, Howard Lewis Ship hls...@gmail.com wrote:
I'm cringing at the sight of XML here.
XML is frequently overused, but it is a good format for representing
dense, structured data. For example:
repository name=third-party
package name=Compojure href=/compojure.xml/
/repository
Compared to:
{:type :repository
:name third-party
:content [{ :type :package
:name Compojure
:href /compojure.xml }]}
Surely we can do better with s-expressions:
(:repository third-party [(:package Compojure /compojure.xml)])
I guess it might get a bit trickier if you have a lot of optional attributes...
And you can use the s-expressions as an on the wire interchange format
as well, which works especially well if both ends are written in lisp.
--
! Lauri
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Package manager proposal
Ruby and Gem is such great terminology, can we come up with something
half as cool?
Want something short (3 - 4 letters) suitable as a file extension perhaps.
Brainstorming some ideas:
cap: Clojure Archive Package
cpa: Clojure Package Archive
ca: Clojure Archive
car: Clojure Archive (half-assed pun on Lisp's car, plus you can
imagine the icon!)
clib: Clojure Library
clip: Clojure Library Package
On Fri, Aug 7, 2009 at 2:17 AM, Lauri Pesonenlauri.peso...@iki.fi wrote:
2009/8/6 James Reeves weavejes...@googlemail.com:
On Aug 6, 8:31 pm, Howard Lewis Ship hls...@gmail.com wrote:
I'm cringing at the sight of XML here.
XML is frequently overused, but it is a good format for representing
dense, structured data. For example:
repository name=third-party
package name=Compojure href=/compojure.xml/
/repository
Compared to:
{:type :repository
:name third-party
:content [{ :type :package
:name Compojure
:href /compojure.xml }]}
Surely we can do better with s-expressions:
(:repository third-party [(:package Compojure /compojure.xml)])
I guess it might get a bit trickier if you have a lot of optional
attributes...
And you can use the s-expressions as an on the wire interchange format
as well, which works especially well if both ends are written in lisp.
--
! Lauri
--
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
-~--~~~~--~~--~--~---
Re: Package manager proposal
Hi, On Aug 7, 11:45 am, Howard Lewis Ship hls...@gmail.com wrote: car: Clojure Archive (half-assed pun on Lisp's car, plus you can imagine the icon!) The other half of the pun's ass is on Java's jar. ;) .cljp: clojure package .clja: clojure archive Playing with Clojure's source extension .clj. Sincerely Meikel --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
On 07/08/2009, at 7:15 PM, Howard Lewis Ship wrote: Ruby and Gem is such great terminology, can we come up with something half as cool? Closure and Resolution, are a pair of parallel hononymic puns. Or Clojure/Seal - you close the package and seal it. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Nothing is really work unless you would rather be doing something else. -- J. M. Barre --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
.car +1 (jar pun)
On Aug 7, 5:45 am, Howard Lewis Ship hls...@gmail.com wrote:
Ruby and Gem is such great terminology, can we come up with something
half as cool?
Want something short (3 - 4 letters) suitable as a file extension perhaps.
Brainstorming some ideas:
cap: Clojure Archive Package
cpa: Clojure Package Archive
ca: Clojure Archive
car: Clojure Archive (half-assed pun on Lisp's car, plus you can
imagine the icon!)
clib: Clojure Library
clip: Clojure Library Package
On Fri, Aug 7, 2009 at 2:17 AM, Lauri Pesonenlauri.peso...@iki.fi wrote:
2009/8/6 James Reeves weavejes...@googlemail.com:
On Aug 6, 8:31 pm, Howard Lewis Ship hls...@gmail.com wrote:
I'm cringing at the sight of XML here.
XML is frequently overused, but it is a good format for representing
dense, structured data. For example:
repository name=third-party
package name=Compojure href=/compojure.xml/
/repository
Compared to:
{:type :repository
:name third-party
:content [{ :type :package
:name Compojure
:href /compojure.xml }]}
Surely we can do better with s-expressions:
(:repository third-party [(:package Compojure /compojure.xml)])
I guess it might get a bit trickier if you have a lot of optional
attributes...
And you can use the s-expressions as an on the wire interchange format
as well, which works especially well if both ends are written in lisp.
--
! Lauri
--
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
-~--~~~~--~~--~--~---
Re: Package manager proposal
car: Clojure Archive (half-assed pun on Lisp's car, plus you can imagine the icon!) +1 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
+1 on .car here too. Plus, I imagine the icon to be a 1950's-era muscle car; a nod to Lisp's age. On Fri, Aug 7, 2009 at 8:13 AM, Justin Johnsonjus...@honesthacker.com wrote: car: Clojure Archive (half-assed pun on Lisp's car, plus you can imagine the icon!) +1 -- Chris Wilson christopher.j.wil...@gmail.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
I like the name Clojure Archive. On another note, I always wondered why xml was such a requirement for Java dependency management. Couldn't we design some sort of url schema, that you could just pass to a package importer in the program. First time you run, it could fetch the packages or automatically check for upgrades etc. This could be managed in an external file if that seems safer. Just a simple manager that could wget the jars (which is all essentially that package managers like ruby gems do). On a slightly unrelated note, how might we index packages for exploration? I think that packages should be indexed both by descriptions provided by the author and by comments within the code itself, in the docstrings of the fn's. Eventually, maybe we could cherry pick namespaces and even pull specific functions! Mark --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
On Aug 7, 1:51 pm, Sean Devlin francoisdev...@gmail.com wrote: .car +1 (jar pun) I'll go against the crowd and say I don't like this name. It seems confusing to have a car symbol in your source code that has an entirely different purpose to its traditional binding. - James --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
On Aug 7, 10:17 am, Lauri Pesonen lauri.peso...@iki.fi wrote: Surely we can do better with s-expressions: (:repository third-party [(:package Compojure /compojure.xml)]) Not very forward compatible, though. Perhaps we should sidestep the whole question about the format of package metadata. At some point, the metadata will have to be parsed into a Clojure data structure, so we could have a parsing multimethod that could take a variety of different input formats. This would allow Maven repositories (in XML) to co-exist with Clojure repositories (in S-Exprs). - James --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
I like this idea too, because if you end up wanting to port this package manager to CLR, Parrot, or JS, you're less tied down to the package formats of specific platforms. Heck, even if Clojure was ported to Ruby (not that there'd be any point to do that), you could wrap the Gems framework. On Sat, Aug 8, 2009 at 1:30 AM, James Reeves weavejes...@googlemail.comwrote: On Aug 7, 10:17 am, Lauri Pesonen lauri.peso...@iki.fi wrote: Surely we can do better with s-expressions: (:repository third-party [(:package Compojure /compojure.xml)]) Not very forward compatible, though. Perhaps we should sidestep the whole question about the format of package metadata. At some point, the metadata will have to be parsed into a Clojure data structure, so we could have a parsing multimethod that could take a variety of different input formats. This would allow Maven repositories (in XML) to co-exist with Clojure repositories (in S-Exprs). - James -- John --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
Hi Meikel, 2009/8/5 Meikel Brandmeyer m...@kotka.de: Well, this is independent of whether you have a C or Java library. You can install each C library in its own directory and tell the linker to look there. Then you have basically a .jar like setup: If you don't tell the linker the right directory the library is not there. Similar you can declare /usr/java/lib as your global directory and unzip each and every jar there. Then configure your java launcher to add that directory to the classpath and you have a setup, like the usual one for C libraries. So this could even be system policy. What I was trying to say is that in the native lib world there are standard locations that the linker has been configured to look at and as a result the user does not have to do anything. That's not the case in the Java world, where the user has to always set the classpath to point to libs that the app uses. My point is that life is easier for languages that use native libraries as extensions rather than Java, because things just work. Placing all my jar files in /usr/java/lib only solves the problem for me if I tell the JVM to look there, plus the JVM will not resolve jars unless I name each jar separately on the classpath, and finally putting all my jars in one directory will not help the users of my package since it's not a universal convention. In the Ruby world, Gems expect their native dependencies to be installed on the platform at Gem install time. The Gem install will fail if the native library is missing. It is up to the user to install the dependency before trying to install the Gem. The user is free to install the dependency in which ever manner he chooses: a source install, a binary install, install via another package manager (e.g. apt-get or MacPorts) etc. Drawing a parallel between Ruby and Clojure, a Clod package could expect jars to be available on the platform at package install time. It would be up to the user to install those jars before trying to install a Clod package. The user is free to install the jar either manually, with Ivy, or with Maven. The trick here is to make those jars available for each invocation of the JVM and I have no idea what the state of the art is here. You can always make it work with some shell scripts or a little bit of ELisp, but that doesn't really feel right to me. So why have all the other programming language package management systems like Ruby Gems, easy install, hackage decided not to worry about native dependencies? Is it simply because it would be difficult to do in a portable way covering all the various Linux systems, and OS X, and Windows? Or is there some other reason? And should the Clojure package manager punt in a similar fashion, i.e. simply let the user handle the Java dependencies? All these setups can be done (more or less comfortable) with today existing solutions for Java. Instead of re-inventing those, it would be more useful to abstract away their specifics. Create a meta-package manager which creates JVM, CLR and whatever packages sitting on the existing infrastructure for the respective platform. Agreed, we shouldn't reinvent the wheel for managing jar files when there are perfectly good solutions out there. AFAICT Meikel would like the package manager to automatically install jar dependencies, but it should use e.g. Ivy to do it? Sounds good to me, although I still feel that as a first step the package manager could simply worry about Clojure packages and expect the user to install dependencies either manually or with Ivy. A later iteration of the package manager could then include dependency URIs that result in third party package manager execution (e.g. Ivy), although it sounds like this will get ugly soon if we need to support more than a handful of underlying package managers with different package naming conventions etc. In any case, I agree with Sean, James should just go for it and we'll see how it works out. Sincerely Meikel -- ! Lauri --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
On Thu, Aug 6, 2009 at 4:12 PM, Lauri Pesonenlauri.peso...@iki.fi wrote: 2009/8/5 Meikel Brandmeyer m...@kotka.de: Well, this is independent of whether you have a C or Java library. You can install each C library in its own directory and tell the linker to look there. Then you have basically a .jar like setup: If you don't tell the linker the right directory the library is not there. Similar you can declare /usr/java/lib as your global directory and unzip each and every jar there. Then configure your java launcher to add that directory to the classpath and you have a setup, like the usual one for C libraries. So this could even be system policy. What I was trying to say is that in the native lib world there are standard locations that the linker has been configured to look at and as a result the user does not have to do anything. That's not the case in the Java world, where the user has to always set the classpath to point to libs that the app uses. My point is that life is easier for languages that use native libraries as extensions rather than Java, because things just work. Placing all my jar files in /usr/java/lib only solves the problem for me if I tell the JVM to look there, plus the JVM will not resolve jars unless I name each jar separately on the classpath, and finally putting all my jars in one directory will not help the users of my package since it's not a universal convention. In the Ruby world, Gems expect their native dependencies to be installed on the platform at Gem install time. The Gem install will fail if the native library is missing. It is up to the user to install the dependency before trying to install the Gem. The user is free to install the dependency in which ever manner he chooses: a source install, a binary install, install via another package manager (e.g. apt-get or MacPorts) etc. Yes, but the global approach is extremly unflexible. While I can see that you probably never want to have two different versions of yor X11 libraries on the system, if you happen to want them, it's probably going to be a major hassle to manage (unless you use a VM for it). Scenario: You have an application as v1.0 in production and it uses a library X in v2.1 (or whatever). Now you're developing developing the next version of your application (v2.0) and you're upgrading library X (to v3.0) in your system since you want the new functionality. The new X v3.0 is not backwards compatible. You find a critical bug in the production version v1.0 while you're happily developing for v2.0 of your app. With your version control system, checking out a parallel install for the production version (v1.0) is easy. With the proposed package manager / dependency system, can you have both versions of said application on your system and launch them without reconfiguration? If you have the classpath setup as a project local dependency file, then you can do this (this is what maven/ivy/virtualenv(python)/zc.buildout(python)/etc. gives you). If you have a global static dependency resolution (path or whatever), then it's going to be diffcult. Whatever approach is chosen (rewrite/wrap/use existing), IMHO this scenario has to be supported by the final system. All these setups can be done (more or less comfortable) with today existing solutions for Java. Instead of re-inventing those, it would be more useful to abstract away their specifics. Create a meta-package manager which creates JVM, CLR and whatever packages sitting on the existing infrastructure for the respective platform. Have a look at Buckminster: http://www.eclipse.org/buckminster/ Not sure if it's going to work for non-JVM approaches (you'll probably have to code up a plugin of some sort), but it's a meta package manager, and can do more than just dependency resolution. For instance, you can specify, if you would like to have a dependency as a published Jar, or if you would like it to be checked from the version control system, so that you can fix bugs in the dependency. Note that this is the most under-documented project I have found in a long time. It's powerful, but unless you use the Eclipse IDE, it's not easy to have it do your bidding. So it might or might not be of interest for our problem. I personally think that the JVM ecosystem became more important because of the dependency configuration approach, since although it's painful to manage if you don't have tools, it's powerful for mixing and matching dependencies in multiple projects on the same machine. This gives you the possibility to try out without jeopardizing your existing project configurations. Just my two cents, Daniel --~--~-~--~~~---~--~~ 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
Re: Package manager proposal
On 06/08/2009, at 8:58 PM, Daniel wrote: Have a look at Buckminster: http://www.eclipse.org/buckminster/ Not sure if it's going to work for non-JVM approaches (you'll probably have to code up a plugin of some sort), but it's a meta package manager, and can do more than just dependency resolution. For instance, you can specify, if you would like to have a dependency as a published Jar, or if you would like it to be checked from the version control system, so that you can fix bugs in the dependency. Note that this is the most under-documented project I have found in a long time. This is the first I've heard of this project, but what about the 255 page user guide available from: http://mirror.cc.vt.edu/pub/eclipse/tools/buckminster/doc/BuckyBook.pdf ? Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 If at first you don’t succeed, try, try again. Then quit. No use being a damn fool about it -- W.C. Fields --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
On Thu, Aug 6, 2009 at 7:07 PM, Antony Blakeyantony.bla...@gmail.com wrote: This is the first I've heard of this project, but what about the 255 page user guide available from: http://mirror.cc.vt.edu/pub/eclipse/tools/buckminster/doc/BuckyBook.pdf ? Ah, nice one. Hasn't been there last time I checked, thanks for the pointer. Cheers, Daniel --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
Lauri Pesonen lauri.peso...@iki.fi writes: Drawing a parallel between Ruby and Clojure, a Clod package could expect jars to be available on the platform at package install time. It would be up to the user to install those jars before trying to install a Clod package. The user is free to install the jar either manually, with Ivy, or with Maven. Installing Java dependencies is usually the only nontrivial step in building a Clojure project. If a package manager doesn't handle this, it's not very useful to me. Luckily it turns out building on the Maven repository format is actually *really easy*; I've implemented it in Corkscrew in about two hundred lines of code. Ivy uses Maven's repository format, so this supports pretty much everything out there modulo the Java folks who are crazy enough to perform dependency resolution by hand. -Phil --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
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 Reevesweavejes...@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 nameJames Reeves/name emailjree...@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 sha196dbe80bf4d897e08858eafdfa5ccab1de1886b8/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
Re: Package manager proposal
On Aug 6, 8:31 pm, Howard Lewis Ship hls...@gmail.com wrote:
I'm cringing at the sight of XML here.
XML is frequently overused, but it is a good format for representing
dense, structured data. For example:
repository name=third-party
package name=Compojure href=/compojure.xml/
/repository
Compared to:
{:type :repository
:name third-party
:content [{ :type :package
:name Compojure
:href /compojure.xml }]}
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)]))
I think you've misunderstood. The format you outline is almost exactly
what I first had in mind as the user interface. I was suggesting an
XML format as the syntax the packager uses internally to communicate
with the repository servers.
For the user, I was thinking of a syntax like:
(package/get compojure 0.2)
This would download compojure from a repository, then dynamically
add it to the Clojure classpath. The repositories would be a list of
URLs the user could add to, similar to Apt's sources.list.
I thought about integrating :use and :require into a 'packages' macro,
pretty much exactly as you've done, but I've since discarded that
approach. Once you put version number logic in, the syntax starts to
get messy. Additionally, a package name might not match up to it's
namespace. Also, how many levels of .s do you go to find the package
name? compojure.html belongs to the compojure package, whilst
clojure.contrib.json.read belongs to the clojure.contrib package.
Instead, perhaps something like:
(package/get compojure 0.2)
(package/get clojure-contrib [:= 1.0-alpha3])
(ns example
(:use 'clojure.contrib.json.read)
(:use 'compojure.html))
You could add (require 'package) to user.clj to ensure that it's
always loaded into the user namespace.
Behind the scenes, the package/get function would be communicating
with a web service containing the packages and package metadata. It
would download and cache the packages in some user-configurable
directory.
At the REPL, the user could also query packages:
user= (package/list)
clojure-contrib
compojure
...
user= (:description (package/query compojure))
A functional web framework
- James
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Package manager proposal
On Aug 6, 10:16 pm, James Reeves weavejes...@googlemail.com wrote: (package/get compojure 0.2) (package/get clojure-contrib [:= 1.0-alpha3]) (ns example (:use clojure.contrib.json.read) (:use compojure.html)) I had another thought once after I posted. Perhaps the best of both syntax ideas could be combined: (packages (:get compojure 0.2) (:get clojure-contrib [:= 1.0-alpha3])) (ns example (:use clojure.contrib.json.read) (:use compojure.html)) - James --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
Or really work this into core and add :packages to the (ns) macro. On Thu, Aug 6, 2009 at 2:30 PM, James Reevesweavejes...@googlemail.com wrote: On Aug 6, 10:16 pm, James Reeves weavejes...@googlemail.com wrote: (package/get compojure 0.2) (package/get clojure-contrib [:= 1.0-alpha3]) (ns example (:use clojure.contrib.json.read) (:use compojure.html)) I had another thought once after I posted. Perhaps the best of both syntax ideas could be combined: (packages (:get compojure 0.2) (:get clojure-contrib [:= 1.0-alpha3])) (ns example (:use clojure.contrib.json.read) (:use compojure.html)) - 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
Hello, Not a great contribution to the debate, but just a word on the terminology: reusing package which already has a strong meaning in java may not be a good idea, I think. I think lib or library could be interesting, but it has also been attributed a meaning more similar to ns description in clojure (and I regret it, but that's another story). So maybe just jars/jar (but that may seem too low level or java oriented), or as in ivy/maven dependencies/dependency (or deps/dep for short) ? Or or ... something different from package :-) 2009/8/7 Howard Lewis Ship hls...@gmail.com Or really work this into core and add :packages to the (ns) macro. On Thu, Aug 6, 2009 at 2:30 PM, James Reevesweavejes...@googlemail.com wrote: On Aug 6, 10:16 pm, James Reeves weavejes...@googlemail.com wrote: (package/get compojure 0.2) (package/get clojure-contrib [:= 1.0-alpha3]) (ns example (:use clojure.contrib.json.read) (:use compojure.html)) I had another thought once after I posted. Perhaps the best of both syntax ideas could be combined: (packages (:get compojure 0.2) (:get clojure-contrib [:= 1.0-alpha3])) (ns example (:use clojure.contrib.json.read) (:use compojure.html)) - 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
2009/8/4 Meikel Brandmeyer m...@kotka.de: I think, clojure context is underestimating things. The high integration of external Java libraries makes it necessary that such dependencies can be handled in the same way. Agreed. I was actually going to write that whatever approach is chosen it must be able to handle Java dependencies as well, but somehow it got lost in the edits ;-) John Newman brought up a good point as well concerning support for other possible clojure platforms like JS, CLR, and Parrot: if we support Java library packaging than shouldn't we also support packaging on other platforms? Maybe the first step should be to provide something that works for clojure code and worry about Java / C# / ... libraries only later? Btw. how does Ruby Gems deal with external dependencies like C libraries? Will the gem install simply fail if an external dependency is not met? And is that analogous to a missing Java library in Clojure's case? I guess one difference is the fact that an installed C library (at least on Unix) is installed in a globally accessable location on the filesystem, whereas Java libs don't have such conventions (or do they these days?). Sincerely Meikel -- ! Lauri --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
Hi, On Aug 5, 10:32 am, Lauri Pesonen lauri.peso...@iki.fi wrote: John Newman brought up a good point as well concerning support for other possible clojure platforms like JS, CLR, and Parrot: if we support Java library packaging than shouldn't we also support packaging on other platforms? The history book on the shelf / is always repeating itself. I think there was some meta package manager, which created from one description a .deb, .rpm, .tgz, whatever to bridge the Linux distros. Something like that would be necessary than. I'm not sure something like that exists to create an installer for Unix, Windows and OS X from the same description. Maybe the first step should be to provide something that works for clojure code and worry about Java / C# / ... libraries only later? opinion I'm sorry. No. I think one of the big pluses of Clojure is the easy integration of the quadrizillion Java libraries out there. So I don't have to wait for a Clojure implementations of some particular library. I think it will still be a long way until such a wealthy flora of libraries will exist in pure Clojure. If the packager doesn't solve my problems *now*, I don't need it. /opinion Btw. how does Ruby Gems deal with external dependencies like C libraries? Will the gem install simply fail if an external dependency is not met? And is that analogous to a missing Java library in Clojure's case? I guess one difference is the fact that an installed C library (at least on Unix) is installed in a globally accessable location on the filesystem, whereas Java libs don't have such conventions (or do they these days?). Well, this is independent of whether you have a C or Java library. You can install each C library in its own directory and tell the linker to look there. Then you have basically a .jar like setup: If you don't tell the linker the right directory the library is not there. Similar you can declare /usr/java/lib as your global directory and unzip each and every jar there. Then configure your java launcher to add that directory to the classpath and you have a setup, like the usual one for C libraries. So this could even be system policy. All these setups can be done (more or less comfortable) with today existing solutions for Java. Instead of re-inventing those, it would be more useful to abstract away their specifics. Create a meta-package manager which creates JVM, CLR and whatever packages sitting on the existing infrastructure for the respective platform. Then it is also possible to hook from the platform into Clojure. I think I saw something like Accessing Clojure from Jython/JRuby/Jsomething. So even none-Clojure projects might want to use a clojure library for some reason. Providing them platform-usual dependency handling would be an additional plus. Any CLR experts around? How does the packaging work there? Sincerely Meikel --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
On 5 Aug., 12:07, Meikel Brandmeyer m...@kotka.de wrote: Any CLR experts around? How does the packaging work there? Well, there's NMaven: http://nmaven.codeplex.com/Wiki/View.aspx?title=Getting%20Started - not sure, though, how popular this is. The CLR has a built-in versioning concept, which may have an impact on the design for a packaging system for .NET. Claus --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
On Aug 4, 2:44 pm, Sean Devlin francoisdev...@gmail.com wrote: James, Just go for it. You've certainly proved you can design a library. Deliver something that works for you, and tell us if you think it's ready. If it's better than other stuff (which I suspect it will be), the community will start using it. If not, back to the drawing board. You're probably right. I'll try and knock something up this weekend that demonstrates the basic concepts. Regarding compatibility with Ivy and Maven, that should be relatively straightforward. There could be a gateway server that transforms the metadata from the Maven repository into whatever format Clod will use. I'm also wondering whether or not I could construct a package manager that operates from within the REPL. Hmm. - James --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
I'm also wondering whether or not I could construct a package manager that operates from within the REPL. Hmm. Well, if it's written in Clojure you get this one for free right? BECAUSE THAT WOULD BE AWESOME! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
On Aug 4, 5:40 am, Phil Hagelberg p...@hagelb.org wrote: Maven actually supports dependency resolution. While I don't like Maven much for most things, its dependency resolution mechanism and repository format is quite good. Regarding Maven and Ivy, their dependency resolution appears to be somewhat different to the design I outlined. Please correct me if I'm wrong, but both Maven and Ivy appear to be designed to resolve dependencies during build time. I'm proposing a system more like Rubygems, one that downloads packages on command and is integrated with the clj classpath. Something like: $ clod install foo = installing... done. $ clj user= (use 'foo) Another big difference is that Maven and Ivy appear to use centralised repositories. I'm proposing what amounts to a distributed repository. - James --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
Please correct me if I'm wrong, but both Maven and Ivy appear to be designed to resolve dependencies during build time. Ivy can be used as set of Ant tasks, stand-alone command line tool or as a library. If used as a library there is nothing stopping you to resolve your dependencies at runtime. $ clod install foo = installing... done. $ clj user= (use 'foo) This looks like offline usage just as with any build tool. Another big difference is that Maven and Ivy appear to use centralised repositories. I'm proposing what amounts to a distributed repository. There is no centralized repository with Ivy. You can build one, but with Packager resolver every project can create its own repository, it can even keep it in /repo dir in its git/hg/svn tree. -- Krešimir Šojat --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
On Aug 4, 10:57 am, Krešimir Šojat kso...@gmail.com wrote: Ivy can be used as set of Ant tasks, stand-alone command line tool or as a library. If used as a library there is nothing stopping you to resolve your dependencies at runtime. Could you give me an example of how you'd use Ivy in a standalone capacity? I was unable to find an example of Ivy being used in the same way one would use Rubygems or Apt. There is no centralized repository with Ivy. You can build one, but with Packager resolver every project can create its own repository, it can even keep it in /repo dir in its git/hg/svn tree. I was aware that Ivy could use multiple repositories, but as far as I can tell, it doesn't allow for a single repository to be distributed over several servers. - James --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
Coming from Ruby land and having used other languages before, I feel rubygems is quiet a good solution to this problem. Having something like this in Clojure would be terrific for a person like me who is just starting up. $ clod install foo = installing... done. $ clj user= (use 'foo) This looks like offline usage just as with any build tool. It is not. It can be both online or offline. If the libraries are not present locally it will try to download them from the central repo. gem install hpricot in ruby will download hpricot library and it's dependencies from a remote repo. and install them. You may also optionally provide the version number by saying gem install hpricot -v 1.1.5 and it will download and install version number 1.1.5 instead of the latest one. Rubygems cannot however download/install non-ruby libraries. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
Hi, On Aug 4, 1:21 pm, James Reeves weavejes...@googlemail.com wrote: Could you give me an example of how you'd use Ivy in a standalone capacity? I was unable to find an example of Ivy being used in the same way one would use Rubygems or Apt. You can do java -jar ivy.jar --help to see the options you have, when running on standalone. You'll still need (at least) an ivy.xml, IIUC. But using Ivy as a library providing a cli client which constructs the necessary objects in memory would make this unnecessary, I think. I was aware that Ivy could use multiple repositories, but as far as I can tell, it doesn't allow for a single repository to be distributed over several servers. You can have separate servers for ivy.xmls and artifacts. However the problem is that this is configured on a per repository basis. So one can't have to two ivy.xmls in the same repository with different artifact patterns. At least that is my understanding. 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. I think the need is already there: any system not leveraging the existing Maven and Ivy repos is pretty uninteresting given the easy integration with Java libraries. Sincerely Meikel --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
Hi to myself, On Aug 4, 1:45 pm, Meikel Brandmeyer m...@kotka.de wrote: You can have separate servers for ivy.xmls and artifacts. However the problem is that this is configured on a per repository basis. So one can't have to two ivy.xmls in the same repository with different artifact patterns. At least that is my understanding. And reading up on the link Kresimir posted, the Packager resolver sovles exactly that problem. :) Sincerely Meikel --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
On 4 kol, 13:21, James Reeves weavejes...@googlemail.com wrote: Could you give me an example of how you'd use Ivy in a standalone capacity? I was unable to find an example of Ivy being used in the same way one would use Rubygems or Apt. In your project you would create standard ivy.xml and ivysettings.xml files as described on Ivy site. Download Ivy (and Ant jars if you will create or use Packagers). After that you can retrieve your dependencies from command line with: java -cp path-to-ivy:opt-path-to-ant org.apache.ivy.Main -verbose - settings ivysettings.xml -ivy ivy.xml -retrieve lib/[artifact]- [revision].[ext] I usualy place that in ivy.sh I was aware that Ivy could use multiple repositories, but as far as I can tell, it doesn't allow for a single repository to be distributed over several servers. You can specify more than one resolver in your ivysettings.xml (and you usualy do), this way you can have more than one server distributing the same repository. Packager resolver can also specify mirror sites for files your are distributing. In Ivy repository description is not mixed with repository files (if you decide that). It can be configured to depend on native extension (good for use with JOGL or JDIC) and even the XML description syntax can be removed if you create alternative loaders for settings and ivy files. To prevent creation of incompatible repositories, maven central repository for instance places Apache Commons CLI in commons- cli:commons-cli:1.3 while ivy roundup repository in org.apache.commons:commons-cli:1.3, there is a namespace mechanism that you can use to rename artifacts. This way there is no need for central naming body and repositories can realy be distributed. -- Krešimir Šojat --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
On Aug 4, 12:51 pm, Krešimir Šojat kso...@gmail.com wrote: In your project you would create standard ivy.xml and ivysettings.xml files as described on Ivy site. Download Ivy (and Ant jars if you will create or use Packagers). After that you can retrieve your dependencies from command line As Piyush mentions, Rubygems is a little more straightforward to use than that. I'd like a package manager where it was not necessary to create a project or write any XML files before use. It might be possible to adapt Ivy into a package manager like this; one that isn't tied to resolving dependencies for one particular project. However, I'm not sure that would be any easier than writing one from scratch. Additionally, there are a couple of benefits to starting from a clean base: certain elements of Ivy's design could be improved, and new features could be more easily added. - James --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
2009/8/4 James Reeves weavejes...@googlemail.com: On Aug 4, 12:51 pm, Krešimir Šojat kso...@gmail.com wrote: In your project you would create standard ivy.xml and ivysettings.xml files as described on Ivy site. Download Ivy (and Ant jars if you will create or use Packagers). After that you can retrieve your dependencies from command line As Piyush mentions, Rubygems is a little more straightforward to use than that. I'd like a package manager where it was not necessary to create a project or write any XML files before use. Don't other people mind all that XML that is related to Ant and Ivy and many Java projects? I'm not saying XML is categorically bad, it's just a pain to write and there are nicer alternatives available these days. Simply just using s-expressions would be more elegant, easier to write, and easier to parse from Clojure. (Note: I've been writing Ant macros for the past few weeks and I'm starting to develop a very serious case of XML allergy.) OTOH it seems like a waste of time to develop something from scratch if there already exists a perfectly good solution that could be tweaked a bit to work in a clojure context. - James -- ! Lauri --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
Meikel said, I think, clojure context is underestimating things. The high integration of external Java libraries makes it necessary that such dependencies can be handled in the same way. On the other hand, will this package system be able to stradle and accommodate future platforms for Clojure, like JS and CLR, or even Parrot implementations? -- John --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
James Reeves weavejes...@googlemail.com writes: On Aug 4, 12:51 pm, Krešimir Šojat kso...@gmail.com wrote: In your project you would create standard ivy.xml and ivysettings.xml files as described on Ivy site. Download Ivy (and Ant jars if you will create or use Packagers). After that you can retrieve your dependencies from command line As Piyush mentions, Rubygems is a little more straightforward to use than that. I'd like a package manager where it was not necessary to create a project or write any XML files before use. I wholeheartedly agree. The main difference between Rubygems and what you would need with Clojure is that Ruby can modify the load-path at runtime, while Clojure cannot. Because of this, Corkscrew unpacks all the dependencies into a subdirectory within the project itself so they are all in one place. It might be possible to adapt Ivy into a package manager like this; one that isn't tied to resolving dependencies for one particular project. However, I'm not sure that would be any easier than writing one from scratch. I don't know about Ivy, but wrapping Maven is quite trivial. Corkscrew is only about 200 LOC and already supports all the interesting bits. Ivy actually borrows Maven's repository format, so there's only one to support there. -Phil --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
Hi, There is Apache Ivy (http://ant.apache.org/ivy/) with it's Packager resolver that does exactly that (it has almost the same syntax as your proposal). For a repository using Apache Ivy + Package take a look at Ivy RoundUp (http://code.google.com/p/ivyroundup/), good thing about there desing is that serve there package repository straight from there svn repository so history is tracked. -- Krešimir Šojat --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Package manager proposal
James Reeves weavejes...@googlemail.com writes:
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.
I agree that this is a very real need for Clojure. I cringe every time I
check out a project that has a lib/ directory full of jar files, but
right now the alternatives are not quite there yet.
Maven actually supports dependency resolution. While I don't like Maven
much for most things, its dependency resolution mechanism and repository
format is quite good. It's hard to recommend that Lispers use a system
that's configured in XML (yuck!), so I've created a tool called
Corkscrew that lets you specify your dependencies in Clojure code:
{:name my-sample
:version 1.0
:namespaces '(my-sample)
:dependencies [[rome 0.9]]
:source-dependencies [[clojure-contrib r663 :svn
http://clojure-contrib.googlecode.com/svn/trunk;]
[enlive 95b2558943f50bb9962fe7d500ede353f1b578f0
:git git://github.com/cgrand/enlive.git]]}
Behind the scenes this is converted to XML that Maven understands, but
it lets you handle transitive dependencies out of the box (in this
example Rome depends on JDom, but you don't have to know that) without
the crazy mess of configuring Maven.
This also has the significant advantage of supporting the thousands of
Java libraries out there that exist as Maven artifacts; if we as a
community were to roll our own package format it would be a lot of work
to republish all these. Corkscrew also supports dependencies on projects
kept in Git and SVN as long as they are just Clojure code.
http://github.com/technomancy/corkscrew
There's lots of room for improvement, but I'm convinced that building on
existing solutions is the right way to go even if Corkscrew itself turns
out to be impractical. It's tempting to underestimate the complexity of
a package manager, but as one of the developers of the Rubygems project,
I can tell you that there are edge-cases within edge-cases, and it gets
hairy quickly.
-Phil
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
