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.
