This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-10-16
Channels
- # announcements (7)
- # babashka (1)
- # beginners (25)
- # calva (7)
- # cider (15)
- # clj-kondo (13)
- # cljdoc (14)
- # clojure (151)
- # clojure-europe (4)
- # clojure-hamburg (2)
- # clojure-italy (22)
- # clojure-nl (57)
- # clojure-spec (12)
- # clojure-uk (6)
- # clojuredesign-podcast (5)
- # clojurescript (12)
- # core-async (8)
- # cursive (26)
- # datascript (9)
- # datomic (92)
- # emacs (4)
- # fulcro (7)
- # graalvm (1)
- # graphql (2)
- # instaparse (3)
- # jobs (1)
- # jvm (2)
- # kaocha (6)
- # nrepl (3)
- # off-topic (5)
- # re-frame (45)
- # reagent (5)
- # reitit (18)
- # ring (1)
- # shadow-cljs (89)
- # slack-help (9)
- # spacemacs (2)
- # sql (54)
- # tools-deps (75)
- # vim (28)
- # xtdb (17)
- # yada (31)
eya... do we have anything like
for clj -A:new
templates yet?
@goomba clj -A:new
can use all of the Leiningen and Boot templates (they'll just produce whatever they are designed to produce).
whaaaaaaaaaaaaaaaaaaaaaat
But I doubt there are any clj-specific templates out there (yet).
psssshhhh I made one
you made it easy enough even for a @goomba ™️ to figure out
Oh, there are some ... https://clojars.org/search?q=clj-template look for /clj-template
in the name.
cool! 😄 (man I was dangerously close to getting "bing"ed again hahaha)
The main issue is that clj -A:new
can pull in templates from git or local deps (which lein/boot cannot) and those would never be discovered by
Go vote for this issue https://github.com/Dexterminator/clj-templates/issues/3
cough this one appears to be missing a vote button 😅
Give the issue a thumbs up emoji, that votes for it
Is it new that -Sdescribe
shows deps.edn
at the end of :config-files
, and not just the system and user deps?
I think it's always been that way
I don't remember changing anything about it at least
@cfleming It only shows that if you're in a folder that has deps.edn
in it.
@seancorfield Oh, I see, you’re right.
@alexmiller that’s the source of the weird bug the other day where stijn was getting a spurious dep - he’s on linux, which starts IntelliJ in his home directory, and he had half a deps.edn file in his home dir.
and by cool, I mean very confusing and not cool
I think that I usually run -Sdescribe
without setting the CWD since I didn’t realise it was significant.
hey, it is
Any chance of ever getting that vector replaced by a map with actual names for the different paths?
It’s really ambiguous now - this has also caused confusion around the system file being bundled in t.d.a, too
I have a feeling I’ve asked for that previously, but I can’t remember the conclusion.
It needs to be ordered -- that's how the files are merged -- and, for a while, the system one was removed from the list because it got built in (but I think it was restored, at least until tooling catches up with that change?).
Well, it was restored, but I think that's why 🙂
Lots of tooling depends on the vector / order so it couldn't change to be a map, but I guess one or more new keys could be added to the overall describe result.
"Lots" == ?
well that's the one I was aware of :)
I was wondering what else was in the "lots"
Cursive doesn’t really depend on the order per se, but does want to understand which of the files are system/user config files and which are the project files.
that should be easier
True, since the API changed, there should be fewer-to-none using the describe output now 🙂
I've just seen several tool authors talk about reading that list to get at the raw deps.edn
files instead -- although I keep telling them not to do that!
depot
just went through a major rewrite to "unify" its read/check behavior with its write behavior (it will update deps.edn
to use the latest versions of artifacts).
Prior to the rewrite, the read/check behavior used the built-in t.d.a. logic and looked at the resulting deps/versions -- but the write behavior read deps.edn
files directly. Now it does it on both paths which completely broke our usage of the tool 😞
I sent PRs to all the projects I could find using clj -Sdescribe output this summer and it actually emits a big ugly warning to stderr if you use it, which I have seen no one mention
this is via the ctda.reader/clojure-env
I think depot just reads the local deps.edn
by default or the list of files you provide on the command-line otherwise. I don't think it even respects CLJ_CONFIG
.
I am actually working on a bunch of changes in this area right now
we are naming the different deps files
how that affects -Sdescribe output tbd (but not planning to break the existing)
we may need to have a conversation @cfleming to make sure you stay in sync, but I need to work through it a little more first
@seancorfield Right, but you can still apply an ordering to the map elements (i.e. :system
comes before :user
comes before :project
)
the ordering can be independent (or more likely, fixed)
do you call anything in clojure.tools.deps.alpha.script.make-classpath ?
that should all be stable (well, I added ctda.reader/user-deps-location if that's useful)
but I am adding some features that are changing the glue between the clojure script and tda (really all logic in make-classpath)
so if you're replicating that logic, it will need to change
but I should really go finish all that so I can get it in rather than talking here :)
Interesting, thanks. I don’t think that’s relevant to Cursive since IntelliJ doesn’t reliably receive env vars from the shell environment, but I do need to allow users to specify where their user deps.edn file is. I already allow that for users using t.d.a directly, but not for CLI users at the moment.
Speaking of which, what’s the state of play of CLI on Windows? I haven’t followed that.
when you use t.d.a directly, there may be something additional you need to do
https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Windows is capturing many of the issues
I wouldn't say it's done :)
FYI, all I use in clj-new
is
[clojure.tools.deps.alpha :as deps]
[clojure.tools.deps.alpha.reader :refer [default-deps
read-deps]]
[clojure.tools.deps.alpha.util.session :as session]
So I assume I'm safe @alexmiller?let me finish what I'm working on and then I can have things to point at
Haha... OK.
I can't imagine clj-new is going to be affected by any of this
actually it will be able to make use of some new stuff
but I'm going to go work on it :)