On Sun, Jul 3, 2011 at 6:06 PM, Phil Hagelberg <p...@hagelb.org> wrote: > Konrad Hinsen <konrad.hin...@fastmail.net> writes: > >> I am looking for a build tool that fulfills the following requirements: > >> 4) Must handle dependencies in the form of on-disk jar files (not in >> any repository) > > For the record, leiningen can do this by adding a repository with a > file:/// URL; it's just not documented because I think it's a bad idea.
Why? One pillar of Clojure philosophy is to get out of the way and let programmers get the job done, with a minimum of fuss and ceremony. Unlike Java. Requiring any project that has dependencies, even if these are only other local projects, have a repository adds gratuitous ceremony. And this is especially true if the user has little or no prior experience setting up and working with repositories, as they grow their programming skillset. Ordinarily, they would gradually progress from single-file projects to multi-file projects to projects with common, locally-installed third-party libraries and/or other local projects as dependencies, and eventually to projects that use and are hosted on repositories of some sort. Your "I think it's a bad idea" amounts to thinking that forcing the third and fourth steps in that progression to be combined into one single giant leap is a *good* idea, and I'm rather dubious of any such claim. One new source of complexity should be mastered at a time, in my view, absent a *very* good reason, and repositories are definitely a humongous source of complexity, so an especially strong case can be made that that *particular* new source of complexity should be tackled separately from any other. (Just consider: starting out using repositories requires mastering a whole new client/server app type on a par with email, newsgroups, ftp, and the web; then there's all these different hosting alternatives -- maven, github, sourceforge, google code, etc. and sometimes software of the same name or closely related like maven and git, as well as other software like rcs, cvs, and svn; then there's the associated terminology: commits, pull requests, push requesus, branches, masters, forks, checkouts and checkins, and so forth, not all of them applicable to each individual variation on the theme; then there's individual projects' often-partly-unwritten rules regarding forking, commit access, pull/push requests, and what-have-you; and setting up a local repository of one's own means installing a server, securing it, installing a client, learning how to use it, and so on and so forth. Indeed, a lot of people will never before have installed and secured a server of any kind in their entire lives, I expect; that itself is something whose learning I think should probably be tackled separately, but if you haven't already done something like run your own listserv or web server (not just site, you own httpd process which if hacked means your own computer is violated), then starting to use local version control means tackling that at the same time as a load of other new and moderately complex things. To which your recommendation adds a third group of complicated new things. So, it's not even two *steps* combining into one giant leap; it's a step followed by an already-fairly-large *leap* combining into one *ridiculous* leap.) -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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
