Re: Libraries and build management hell

On Mon, Aug 1, 2011 at 3:02 AM, pmbauer wrote: >> I might be able to disprove your scurrilous charge if ... > > I doubt that since your earlier assertion was factually incorrect. If you have a personal problem with me, sort it out in private email or keep it to yourself rather than badmouthing me

Re: Libraries and build management hell

> > I might be able to disprove your scurrilous charge if ... > I doubt that since your earlier assertion was factually incorrect. > > See mvn install:install-file > > > > http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html > > Not relevant. We were discussing use of lein deps. >

Re: Libraries and build management hell

On Aug 1, 9:59 am, Ken Wesson wrote: > On Mon, Aug 1, 2011 at 12:49 AM, pmbauer wrote: > > "What if you have the JAR on a disk somewhere, for other reasons, but > > until now it wasn't a dependency of that particular project?" > > Your assertion that dependency management systems are in any way

Re: Libraries and build management hell

On Mon, Aug 1, 2011 at 12:49 AM, pmbauer wrote: > "What if you have the JAR on a disk somewhere, for other reasons, but > until now it wasn't a dependency of that particular project?" > Your assertion that dependency management systems are in any way > disadvantaged to manual dependency management

Re: Libraries and build management hell

"What if you have the JAR on a disk somewhere, for other reasons, but until now it wasn't a dependency of that particular project?" Your assertion that dependency management systems are in any way disadvantaged to manual dependency management in terms of SPOF or requiring a network connection is

Re: Libraries and build management hell

On Sun, Jul 31, 2011 at 11:57 PM, Sean Corfield wrote: > On Sun, Jul 31, 2011 at 7:49 PM, Ken Wesson wrote: >> If you add a new dependency, the network connection is needed. > > If you add a new dependency and you don't already have the JAR > downloaded, you need a network connection one way or a

Re: Libraries and build management hell

On Sun, Jul 31, 2011 at 7:49 PM, Ken Wesson wrote: > If you add a new dependency, the network connection is needed. If you add a new dependency and you don't already have the JAR downloaded, you need a network connection one way or another to go get that JAR, yes? It doesn't matter what tool you

Re: Libraries and build management hell

On Sun, Jul 31, 2011 at 9:43 PM, yair wrote: > On Jul 31, 12:28 pm, Ken Wesson wrote: >> "Almost" being the operative word. One distinct disadvantage is that >> it makes building your project require a working network connection > > This is not correct.  Once the jar has been downloaded after be

Re: Libraries and build management hell

On Jul 31, 12:28 pm, Ken Wesson wrote: > "Almost" being the operative word. One distinct disadvantage is that > it makes building your project require a working network connection This is not correct. Once the jar has been downloaded after being included in the dependencies, it stays in your lo

Re: Libraries and build management hell

My solution to these problems is my run command, where you can run a script in the dependency context of a particular project. So lets say you have a scratch project with many common dependencies. Then I run anywhere, dj run foo.clj scratch-project. I'd imagine there is something like this for cake

Re: Libraries and build management hell

Mark Engelberg writes: > Phil makes a reasonable point that it is possible to create a single > "project" for one-off tasks. I'm not sure how well that would work > with the way I have things organized, and with my source control, but > it's something I can look into. I have a "scratch" project

Re: Libraries and build management hell

On Sat, Jul 30, 2011 at 5:27 PM, Mark Engelberg wrote: > I guess what I'm > thinking of is that 95% of the time when I go to start something new, > it ends up being for a short-lived task Sounds like both Phil and I tackle that by having one or more scratch projects that we just add new dependenc

Re: Libraries and build management hell

On Sat, Jul 30, 2011 at 10:58 AM, Mark Rathwell wrote: > > 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 v

Re: Libraries and build management hell

On Sat, Jul 30, 2011 at 10:43 AM, Sean Corfield wrote: > On Sat, Jul 30, 2011 at 8:24 AM, Mark Engelberg > wrote: >> 95% of the time, I just want to open a >> file, write some Clojure code, and interactively test it in a REPL. > > Really? Genuine question. You're probably right that by *time*, I

Re: Libraries and build management hell

On Sat, Jul 30, 2011 at 8:24 AM, Mark Engelberg wrote: > And yes, there are certain libraries I tend to use, and I want them to > always be available.  Right now, for every file I want to tinker with, > I have to do lein new make-up-some-project-name.  Then I have to go in > and edit the project.c

Re: Libraries and build management hell

On Sat, Jul 30, 2011 at 7:58 AM, Mark Rathwell wrote: > Maybe a Clojure installer for > Mac/Windows/Linux, that installs a clj executable on the path This was actually how I started with Clojure on Mac OS X (I think the project was Clojure-MacOSX or something like that) but I quickly found it was

Re: Libraries and build management hell

On Saturday, July 30, 2011 6:24:50 PM UTC+3, puzzler wrote: > > The issue I have with the build tools is that they all presume > you want to *build* something. 95% of the time, I just want to open a > file, write some Clojure code, and interactively test it in a REPL. > Exactly what I'm talking ab

Re: Libraries and build management hell

On Jul 30, 2011, at 11:24 AM, Mark Engelberg wrote: > I would love to have a more streamlined way in Clojure for my personal > common case -- writing a short script and using it interactively. +1 on the whole perspective presented here, most of which I cut. -Lee -- You received this message b

Re: Libraries and build management hell

On Sat, Jul 30, 2011 at 7:58 AM, Mark Rathwell wrote: > 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 global

Re: Libraries and build management hell

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 suggeste

Re: Libraries and build management hell

On Sat, Jul 30, 2011 at 5:31 AM, Michal B wrote: > > 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 fo

Re: Libraries and build management hell

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

Re: Libraries and build management hell

Lee Spector writes: > FWIW for some JVM newcomers (like me when I started) #6 involves some > mysteries related to where exactly the jar should be saved and how > exactly the other code can be told to find it. It varies depending on > how you run your code (e.g. whether you have to figure out how

Re: Libraries and build management hell

Hi, On Thursday, July 28, 2011 11:23:58 PM UTC+2, Michal B wrote: > > Why does it have to be so complicated to use libraries? > because it is a complicated topic. Maybe I can compare it to other ecosystems. * CPAN for Perl is a paradise for functionality. However, trying to use CPAN together

Re: Libraries and build management hell

On Jul 28, 10:06 pm, Mark Rathwell wrote: > The problem with jar downloads as the default distribution method is that > non-Java people, and even plenty of Java people, seem to have problems > consistently setting classpaths correctly.  Seems much more straightforward > to just have lein take car

Re: Libraries and build management hell

On Jul 29, 2011, at 8:14 AM, Alex Osborne wrote: > > 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 c

Re: Libraries and build management hell

On 29 July 2011 08:01, Michal B wrote: > Leiningen definitely alleviates the hairiness of library management. But I > wish people won't settle for a lein like solution for simple projects. As > much as it helps, it is still an unnecessary burden and an obstacle to > adoption, in my opinion and exp

Re: Libraries and build management hell

Re: > > 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

Re: Libraries and build management hell

Michal B 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

Re: Libraries and build management hell

On Thu, Jul 28, 2011 at 2:23 PM, Michal B wrote: > Why does it have to be so complicated to use libraries? Heh. My current project is C/C++, and we are using gnu autotools for the build. A few dependencies use pkgconfig, some have m4 macros (that are out of date), one has its own backtick-config

Re: Libraries and build management hell

Hello, I am absolutely new to Clojure and Intellij. I just installed the La Clojure plugin and everything is working. This has been relevant in my decision of which JVM functional language to use. Maybe the over-engineering is indirect Haskell influence (despite being ML descendant): you have to l

Re: Libraries and build management hell

Leiningen definitely alleviates the hairiness of library management. But I wish people won't settle for a lein like solution for simple projects. As much as it helps, it is still an unnecessary burden and an obstacle to adoption, in my opinion and experience. -- You received this message becau

Re: Libraries and build management hell

The situation you describe clearly requires a build tool. But I'm not talking about this case. -- 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 moderate

Re: Libraries and build management hell

The problem with jar downloads as the default distribution method is that non-Java people, and even plenty of Java people, seem to have problems consistently setting classpaths correctly. Seems much more straightforward to just have lein take care of that for you. As for complicated installation

Re: Libraries and build management hell

+1 We build a dozen projects here with a mix of Clojure and Java and we only use Leiningen. The biggest effort was to consolidate the dependency libs pulled by Leiningen in our different projects. You end up with multiple version of the same jar, a result of the dependency solving done by Leini

Re: Libraries and build management hell

I have to chime in my solution to the problem, dj. git://github.com/bmillare/dj.git Acts more like a distro then a build tool though. On Jul 28, 7:49 pm, Sean Corfield wrote: > On Thu, Jul 28, 2011 at 2:23 PM, Michal B wrote: > > Why does it have to be so complicated to use libraries? > > I ca

Re: Libraries and build management hell

On Thu, Jul 28, 2011 at 2:23 PM, Michal B wrote: > Why does it have to be so complicated to use libraries? I can't imagine it being much simpler than using Leiningen... > To use libraries, you need to learn how to operate half a dozen build tools Just one: Leiningen. You can learn Cake or Maven

Re: Libraries and build management hell

i would agree with all that if i were writing plain java (a lib dir for dependencies and a couple of shell scripts for building etc), but leiningen makes it so easy for clojure that its more work _not_ to use it... at least that has been my experience. On Thu, Jul 28, 2011 at 4:23 PM, Michal B wr

Re: Libraries and build management hell

> Why does it have to be so complicated to use libraries? I used to think it was hard until I read up on lein. Can't get much simpler than clojars and lein: http://clojars.org/ http://alexott.net/en/clojure/ClojureLein.html Now I'm starting to think that I actually like the lein method over pyth

Libraries and build management hell

Why does it have to be so complicated to use libraries? 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. If figuring out how to install an IDE with clojure wasn't bad enough, now you need to fi