I'm all for a better, easier solution that is better in most ways. What I'm saying is:
1. I don't want to go back to downloading jar files from the websites of all of the libraries I want to use in a project and tracking different versions, no matter how large or small the project is, as suggested in your OP. I think the centralized lein/clojars/github is an improvement over that in almost every way. 2. I, personally, cannot think of another solution that does not have trade offs, does not mean I am against it if there is one. And, as I said, there are good arguments for and against those trade offs, but to me, personally, I prefer the trade offs of lein over the environment wide solutions a la Perl, Python and Ruby (most of the time). I really think incremental improvements to lein/cake/etc, over time, will yield better results than going back to square one. One thing, though, is new users coming from Python/Ruby/etc really do seem to have a hard time adjusting to the fact the standard is not to have a Clojure installation, with a clj executable that you run scripts through, and with globally installed libraries. Maybe a Clojure installer for Mac/Windows/Linux, that installs a clj executable on the path, and that has its own directory that it adds to the classpath when it is run, where you could install jars (maybe using a lein plugin) that would be available globally, and not interfere with the current standard. But that is yet more choice to overwhelm user, so I don't know. - Mark On Sat, Jul 30, 2011 at 5:31 AM, Michal B <mibu.cloj...@gmail.com> wrote: > This discussion is getting a lot of "What are you talking about? Leiningen > is what you're looking for!" replies. I know. I'm a happy lein user, and use > it and clojars frequently with some of my larger projects. I'm very grateful > for the work Phil and the other > contributors<https://www.ohloh.net/p/leiningen/contributors>did. It helped me > tremendously. There's no need to get defensive. As I tried > to emphasize several times in my post, this was not an attack on lein or > other build tools - they certainly have their place in the development > process. I was trying to get a discussion going on the current library > situation, which I think if everyone took back a step they'd agree is far > from ideal. Lein is a remedy, but not a solution. Is lein as good as it > gets? > > Instead of iterating what's available today and how much better it makes > things (I know), I hope we can question our assumptions about how things are > and get a discussion going on how to make things better. If not for > simplicity, do it for the new users who today when visiting the Getting > Started pages are overwhelmed by rampant choice and endless technical > procedures. > > -- > 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 > -- 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
