This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-07-16
Channels
- # announcements (3)
- # babashka (25)
- # beginners (71)
- # calva (18)
- # clj-kondo (52)
- # cljs-dev (94)
- # cljsrn (12)
- # clojure (33)
- # clojure-europe (52)
- # clojure-nl (2)
- # clojure-uk (27)
- # clojurescript (18)
- # clojureverse-ops (4)
- # datomic (64)
- # deps-new (27)
- # depstar (5)
- # events (5)
- # fulcro (5)
- # graalvm (12)
- # graalvm-mobile (82)
- # helix (2)
- # introduce-yourself (1)
- # juxt (5)
- # lsp (10)
- # malli (7)
- # missionary (1)
- # off-topic (41)
- # pathom (69)
- # pedestal (6)
- # re-frame (4)
- # reagent (8)
- # releases (9)
- # remote-jobs (8)
- # shadow-cljs (3)
- # sql (46)
- # tools-deps (44)
- # uncomplicate (1)
- # vim (83)
https://github.com/seancorfield/clj-new/releases/tag/v1.1.321 -- includes a bug fix for a recent change which switched to using tools.deps.alpha/create-basis
but that requires a project deps.edn
by default, which preventing clj-new
running in directories without deps.edn
. Sorry I didn't catch that earlier 😐
is this something create-basis should fix?
I'd say yes
I guess it would be convenient if create-basis
silently omitted the :project
deps.edn
file if it didn't exist, but there is value in having that be an error to avoid running tools that require deps.edn
in the "wrong" directory.
:project nil
says "do not use deps.edn
" so I think you need a way to distinguish between "use deps.edn
if present" from "must have deps.edn
"?
I'm OK with the current behavior. It just caught me out because I didn't consider the use case of running clj-new
somewhere without deps.edn
(if you're developing a new template, you want clj-new
to use that deps.edn
file because that's where the template's code/deps are going to be declared).
I don't think create-basis should have "must have deps.edn" - that's a constraint a program can check if it wants to but I don't see why create-basis cares
I've made clojure.tools.deps.alpha/slurp-deps tolerant of files that don't exist (which affects everything downstream of it, including this). in general, everything else in the api is tolerant of missing dep sources, seems like this should be too to be consistent
OK, thanks. When I next update clj-new
to a newer t.d.a, I'll try to remember to take that conditional out 🙂