> I've been wondering about this. The classpath issue seems like a > major thorn in the side of the JVM, especially for Clojure and other
It seems to be that there are two problems here. One problem is that there needs to be a convention for a clojure "binary" that works consistently across platforms. I maintain the clojure port in the FreeBSD port collection, and I install an appropriate wrapper script such that you can in fact do: clojure myscript.clj And have it "just work" without further ado. This is something that I think needs to be made more consistent; probably by having the clojure distribution ship with such a script that works on all POSIX shells, and making it clear to packagers that it is intended to be the standard way of invoking clojure. The other issue is that of picking up libraries. Here scripting languages like ruby/python/etc have a well-defined convention for doing this, where you have certain system paths that are intended to contain modules. The exact path will vary with platform (for example as a function of whether you use pycentral, are on debian, freebsd, redhat, etc). I would suggest that clojure could have a concept of "site library path" that would be the responsibility of packagers to set appropriately (just like 'site-packages' for python) where .jar:s would be automatically picked up. Alternatively there could be two such paths; one for a path that gets automatically added to CLASSPATH and one that gets automatically scanned for .jar files. As a practical example, I envision that what for Python might be: /usr/local/python2.5/site-packages/X/Y/Z Would for clojure be: /usr/local/clojure/site-jars and /usr/local/clojure/site-classpath What do people think about this? I think it's all about providing a documented default method of finding libraries; packagers for respective platforms will then follow suit, I think. This also makes it much easier to start packaging clojure libraries in respective platform's packaging systems, where they can install .jar:s in the appropriate place using common infrastructure shared across all clojure packages. So in short: Defining some semantics and interfaces that make sense from the perspective of debian/freebsd/redhat/whatever package management, I think is likely to result in a more consistent end-user experience once package maintainers start picking this up, just like the case is with Python and Ruby. I'd be interested in looking into getting some kind of draft implementation of this, if people think it's a good idea (though I can't make time commitments - busy busy busy). -- / Peter Schuller -- 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
