2013/5/15 Dave Kincaid <kincaid.d...@gmail.com>: > As long as we remember that not everyone is using Leiningen and/or Maven. > There are other build and dependency systems out there, so any change to > dependency management tooling will have to cover all of them. > > There are already popular libraries that don't work outside of Leiningen, > but that's a topic for another thread...
Hello, What are the popular Clojure (not ClojureScript) libraries that don't work outside a maven-style-backed-central-public-repository? > > > On Wednesday, May 15, 2013 3:17:59 AM UTC-5, Glen Mailer wrote: >> >> At the risk of making a slight strawman here, I agree this issue has the >> potential to drag on Clojure adoption - but in the opposite way to what you >> describe. >> >> At the root of it, is the Clojure ecosystem a "dependencies are bad" >> system, or a "dependencies are good" system? >> >> The former encourages roll-your-own, but reduces code sharing and re-use >> The latter promotes sharing and building upon the work of others, but >> requires more advanced dependency management tooling >> >> As great as the language is, having the general advice be "don't have >> dependencies in your libraries" seems like a step backwards to me. >> >> I would always rather spend an hour finding a documented, tested existing >> library, than spend 20 minutes creating my own duplicate of that work. >> >> I hope this doesn't come over as too accusatory, if the cost of >> dependencies truly is higher than the cost of duplicating work/code then >> perhaps we need to try and make the former easier. >> >> Glen >> >> On Tuesday, 14 May 2013 13:19:15 UTC+1, Dave Kincaid wrote: >>> >>> This thread seems to have gotten way off track and I think that Stuart >>> made a very important point in the original post that's getting lost. It >>> would help all of us out if library authors stopped making their libraries >>> dependent on 10+ other libraries. This issue does have the potential to >>> really drag on Clojure adoption. Just try to maintain your own local >>> repository for your projects and you'll see what I mean the first time you >>> need to add a Clojure dependency. >>> >>> On Tuesday, May 14, 2013 4:22:59 AM UTC-5, Phillip Lord wrote: >>>> >>>> Stuart Sierra <ma...@stuartsierra.com> writes: >>>> > On Tue, May 14, 2013 at 3:25 AM, Phil Hagelberg <ph...@hagelb.org> >>>> > wrote: >>>> > >>>> >> It's really not difficult to do if you limit yourself to Clojure >>>> >> since >>>> >> Clojure namespaces are first-class and easy to manipulate at >>>> >> run-time. We implemneted a prototype of this in under two hours at a >>>> >> Seajure meeting a while back: >>>> >> >>>> >> https://github.com/technomancy/metaverse >>>> >> >>>> >> However, it's significantly more difficult to do for arbitrary Java >>>> >> bytecode. >>>> >> >>>> > >>>> > >>>> > That's cool, and it will work for the simple case of libraries A and B >>>> > depending on different versions of C. >>>> > >>>> > But it still breaks down in more complex cases: e.g. if I want to >>>> > share >>>> > data between A and B using a protocol or type defined in C, and there >>>> > are 2 >>>> > incompatible versions of C. Even ClassLoaders can't help you there - >>>> > I'm >>>> > not aware of any solution. >>>> >>>> >>>> Automatically, no, but the solution would be to use something akin to an >>>> adaptor. The two versions of C would be manipulated to be in different >>>> namespaces; now you just have two libraries, so the task of plumbing >>>> them together remains the same. >>>> >>>> To be honest, though, this is unlikely; after all, if you are using A >>>> and B, and they are using C *as a utility*, my feeling is that C >>>> shouldn't really be in their public interface. If C *is* in their public >>>> interface, then again, you need adaptors. >>>> >>>> Or you can fork A and/or B, fix them to use the same version! >>>> >>>> Phil > > -- > -- > 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 unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
