This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-14
Channels
- # announcements (6)
- # architecture (5)
- # aws (4)
- # beginners (79)
- # boot (3)
- # boot-dev (7)
- # calva (21)
- # cider (17)
- # cljdoc (12)
- # clojure (83)
- # clojure-art (2)
- # clojure-belgium (2)
- # clojure-brasil (1)
- # clojure-estonia (2)
- # clojure-europe (3)
- # clojure-finland (5)
- # clojure-india (2)
- # clojure-italy (49)
- # clojure-losangeles (1)
- # clojure-nl (12)
- # clojure-spec (120)
- # clojure-sweden (2)
- # clojure-switzerland (4)
- # clojure-uk (31)
- # clojurescript (80)
- # data-science (17)
- # datavis (2)
- # datomic (31)
- # emacs (31)
- # figwheel-main (28)
- # fulcro (6)
- # jobs (2)
- # liberator (7)
- # luminus (1)
- # nrepl (2)
- # off-topic (51)
- # overtone (2)
- # pathom (4)
- # re-frame (28)
- # reitit (1)
- # rum (6)
- # shadow-cljs (26)
- # specter (2)
- # tools-deps (33)
- # yada (3)
since there is no cognitect channel and this is a tools.deps project, I’ll post it here. there’s a trivial PR lingering for a while now. I wonder why there’s no interesting in accepting it from Cognitect Labs: https://github.com/cognitect-labs/test-runner
Sorry, Luke was minding that project and he’s not at Cognitect anymore
I’ll take a look when I get a chance
@U050ECB92 is this any you became a space cat wizard?
Are there any examples out there of libraries that have both a project.clj
and also a deps.edn
, for compatibility with both Leiningen and tools.deps, but don’t duplicate the dependency specifications? I’m interested in possibly contributing such a feature to a library I use.
:plugins [[lein-tools-deps "0.4.1"]]
is in one of our project.clj files. This allows the lein project to read deps out of the deps.edn file
:plugins [[lein-tools-deps "0.4.3"]]
is the latest and should be a bit quicker at resolution.
I've been using that for quite a while, and it works great. but now Cursive supports deps.edn directly so I mostly use that
lein-tools-deps
is not without its issues… I should probably make them clearer on the repo.
Once I read the docs, I was up and running with no clear issues, at least not at first. Maybe some of the steps could be moved to the top of the readme, but no big deal
Good to know… but it can cause problems if you’re not aware of how it works… and it’s not made clear yet. Essentially it currently flattens the whole transitive dependency graph. It does this to guarantee resolution is the same in both tools.deps and leiningen — but it does mean that downstream mvn resolution semantics can change.
e.g wrt to :exclusions
That sentence seems very important… if it’s not in the readme already maybe just add it as-is?
I think it warrants a small section covering the implications tbh — will write it at some point.
you’re welcome to comment on what is written — but it’ll probably be ok. Too busy to do it just now though.
there are github issues that touch on it already
Makes it very simple to use lein for building/deploying but deps.edn for dev and running
I just pushed https://git.sr.ht/%7Ehiredman/dset/tree up over the weekend, it has both a deps.edn and a project.clj, with all the deps coming from deps.edn
how do you like using http://sr.ht?