Thank you Alex. Regarding 1 I don't think I really see why I would want this but it seems interesting.
Regarding 2 and everything else I'm really happy with the tool and the docs are great. (My cljs usage with this right now is to just build cp and launch figwheel.) Cljs libs and how this is gonna play with cljs's own deps.cljs and npm-deps I'm looking forward very much to a combined effort. Especially if npm dependency resolution will be moved away from the compiler. On Monday, February 26, 2018 at 6:15:55 PM UTC+1, Alex Miller wrote: > > > > On Monday, February 26, 2018 at 10:59:53 AM UTC-6, Leon Grapenthin wrote: >> >> Thank you for this tool. >> >> I'm using this for a rather large new project right now and already love >> how precise and minimalistic this tool is. Features like -Sverbose, -Stree >> and now -Sdescribe are very helpful. >> >> Although it is probably not intended I don't think we will be using >> Leiningen and Boot as much in the long term future as we do now. >> >> Two questions though: >> 1 I'm having trouble understanding :default-deps from the documentation >> ":default-deps provides a set of default coordinate versions to use if >> no coordinate is specified. The default deps can be used across a set of >> shared projects to act as a dependency management system" >> Don't get it. How can a dependency have no coordinate specified? And the >> second sentence I don't understand at all. How is possible to use default >> deps across shared projects and then they become a dependency management >> system ?!? >> > > This stems from some very early design work with the notion of allowing > for an external source of dependency versions shared across projects. So > the idea is that you would declare a lib but not declare a coordinate for > it. And then you would use this with an alias (which could be a shared > alias in your ~/.clojure/deps.edn that applies across projects) to declare > the default dep coordinate versions used across multiple projects. Where we > are at the moment, I'm not sure this is very easy to use or leverage but is > an area with a ton of future potential, similar to ideas of > "dependencyManagement" in maven/lein. We've learned a lot since that early > work and I'm not sure we would come to the same conclusions with a fresh > re-think now. > > >> 2 In a CLJ/CLJS project I'm not using :deps because I have a clj, a >> clj-dev, a cljs and a cljs-dev alias. For development I combine clj and >> clj-dev or cljs and cljs-dev. They all have :extra-deps, but no :deps. Is >> this the intended usage? >> > > I think that's fine - :deps are really declaring dependencies for your > project classpath and importantly for other projects that use your project. > I suspect in your case there are none of the latter (you're an app, not a > lib or a service) and in the former there are really multiple kinds of > classpaths you need to build so this makes sense. > > Most of the original design work was focused on Clojure, not > ClojureScript, so the docs may not be particularly well targeted to your > use and that's why they don't seem to match to your usage well. I think we > could use some good docs, probably on clojurescript.org, with that > intent. Things are both changing and being discovered at a pretty rapid > pace right now around cljs usage of the clj tool. > > -- 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/d/optout.
