On 04.03.2010, at 14:33, Jan Rychter wrote: > It seems that leiningen assumes that you are building an application. It > downloads all dependencies and can build an uberjar for you. That's > great, but what if what I have is a bunch of libraries, all being > developed and modified?
That's my situation as well. I did start to use Leiningen, but only for producing releases for the outside world. On my development machine, it's the source code directories of all libraries that are on my classpath. That way I am sure which version of the code I am running. > with Common Lisp. But now things got worse -- I no longer feel in > control of anything. Some things won't build, lein tells me about > "artifacts" (huh?!), things get installed in weird places. My clj script > that gets run by SLIME form Emacs can't find libraries that leiningen > downloaded. > > How do people deal with this? Here's what works for me. Each of my libraries is one "project" in the sense of swank-clojure. I use swank-clojure-project to start Clojure inside slime, and that takes care of my classpath. All I need to do is have the right stuff in the lib subdirectory of each project, so that's where are all the configuration is done. Instead of doing something like "lein deps" to fill the lib subdirectories, I decided to manage them manually and have only soft links in there that point to the real jars and source directories. There's one soft link to the clojure jar (the one I rebuild after each "git pull" from github), one for clojure-contrib (same principle), and one for swank-clojure (same again). All other dependencies on Clojure libraries are soft links to the source code directory inside the respective project directories. Dependencies on external Java libs are soft links to the jar files, which reside in a single place on my hard disk. > As a more general observation, I think that a large part of Perl's and > Python's success was a unified way of dealing with libraries. There > are certain directories where you can drop libraries and expect them to > work (be found). There is ONE way of running the VM (one script, blessed > by the language creator). Then on top of that there is CPAN, which plugs > into that, downloading dependencies and dropping libraries into those > well-known directories. It isn't perfect, but it works, and is > predictable. Right, but its imperfections have bothered me often enough. For once, if you have different applications that require different versions of the same library, you are in for a major headache. Python setuptools and its eggs are a partial solution, but add a lot of complexity of their own. Another source of endless frustration is maintaining a personal library installation on a machine where I don't have administrator rights and need to work with multiple Python versions. It's possible, but it's a big mess and I need to be very careful to be sure that I really use the version that I need. I am not too unhappy with the JVM approach to configurability via classpath, but it requires a layer of management tools and/or conventions to be productive. What doesn't fit with my JVM world-view is Maven, and thus leiningen. Their dependency handling model is clearly geared towards application deployment rather than library development. Moreover, I think their model is too complicated, making it difficult to predict which jars will end up being used where. But perhaps that's just my lack of experience. > Shouldn't we have a well-known Single Setup for Clojure as well? It would perhaps be a good idea to have one default setup, with the option for expert users to roll their own. For newcomers the current situation is definitely too messy. > I add to classpath once I have a library checked out?). I thought > Leiningen was supposed to solve these issues, but either I am missing > something, or it is really a tool to manage dependencies for a single > application. That's my view of what it is, but I can't claim much experience with it. Konrad. -- 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
