Michal B <mibu.cloj...@gmail.com> writes: > To use libraries, you need to learn how to operate half a dozen build > tools and git because each library author distributes their library > differently.
There is a simple de facto standard, which in typical Clojure-style we've inherited from the Java community for the sake of interoperability. Library authors publish a jar file (which is just a zip of the Clojure source code) to a HTTP repository which has a directory structure following the Maven repository conventions. People don't necessarily have to use Maven, often they use Leiningen or Cake and sometimes they don't use a build tool at all. You can certainly do it by hand or with a shell script easily enough. A popular repository for open source community libraries is Clojars, although some projects like to host their own or use Maven Central. Often companies will have an internal repository which could just be on a directory on a network share somewhere. Some use repository software like Nexus or a local instance of the Clojars webapp, but that's strictly optional. > If figuring out how to install an IDE with clojure wasn't bad enough, > now you need to figure out how to install and use each of the tools > with it. No you don't. Let's suppose we want to add the robert.hooke library to our project without any build tools. 1. Goto http://clojars.org/. 2. Click "browse the repository" (down the bottom). 3. Click "robert". 4. Click "hooke". 5. Click "1.1.2". 6. Click "hooke-1.1.2.jar" and save the jar file to your project. The repository is really nothing more than a bunch of directories each containing a jar files and another file containing a list of dependencies. I'm not sure how you could make it any simpler. Admittedly Clojars' is not perfectly user-friendly and the search and browse could do with improving. I'm not currently motivated to do this work myself (due to lack of time, UI design not being my passion and that it's currently "good enough" for me personally to live with) but the code is open source and I'm happy to take patches that do so. I'm actually kind of hoping that eventually someone with time and vision will come along and slowly take it over. I created Clojars to scratch an itch: I was just really unhappy with the existing options. I maintain it in the sense of keeping it running, but it really is pretty neglected. I really hate thinking about build tools and dependencies, I just want them to work and get out of my way. Unfortunately that means at work I often end up being the "build/deployment guy" just because I'm the first one to gets sufficiently annoyed to go and do something about it. > Instead of having a complicated installation guide for your library, > have a Download section in your site. Have there a link to the latest > stable version of your library as a jar file or, if necessary, a zip > file with your jar and and all the necessary dependency jars (sane > library authors won't mind). For a zip, shortly describe what's in it > - library names and versions, and links to their sites. That's it. This actually is exactly how most Clojure libraries were distributed before the creation of Leiningen. Maven of course existed and some people who had a strong Java background were using it but many were quickly put off by its verbosity, steep learning curve, poor documentation and lack of transparency. So what you describe is exactly what you'd get: ad-hoc heterogeneously structured downloads with an accompanying zip or tarball full of jar dependencies if you were lucky. Said zip files could vary wildly, but could contain something like: clojure.jar contrib.jar clj-http-2011.jar Too bad if you want to know what version a dependency is. Often the clojure and contrib jars were just some random snapshot of SVN (this was before the move to Github). Maybe the library author even modified them themselves so they didn't match a mainline version at all. Even for small projects I would argue this is not simpler, it's more complicated. Now you could argue that it would be quite handy for people who want to avoid tools and configuration files if there was a web site that automatically generated a zip containing a jar and all of its dependencies for download in one go. I can see myself using such a thing from time to time but not for my primary programming. There are some minor security and legal issues (eg license compatibility), but I would be happy take a patch to Clojars that added or integrated with it. It really is just moving the dependency management tool from being client-side to server-side though. > Instead of managing libraries inside a dependencies file, you do it > directly with the jar files. If the project gets too big, bring in the > build tools. > > What are your thoughts on this issue? I think automated dependency management is a necessary evil unless you basically don't reuse code. I don't particularly like dependency management. I don't particularly like build tools in general. But I really don't want to turn back the clock to the time before we (the Clojure community) used it. That was even worse. Hopefully some bright spark will come along and revolutionise dependency management, like how Rich revolutionised the notion of state in programming. As far as I'm aware nobody has so far, for any programming language (or OS distro), I'm not completely happy with any of them. It needs more hammock time. -- 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
