This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-28
Channels
- # announcements (33)
- # aws (2)
- # babashka (14)
- # beginners (128)
- # calva (34)
- # cestmeetup (3)
- # clj-kondo (12)
- # cljdoc (3)
- # clojure (114)
- # clojure-europe (31)
- # clojure-italy (3)
- # clojure-nl (7)
- # clojure-uk (6)
- # clojurescript (35)
- # conjure (20)
- # cursive (3)
- # data-science (3)
- # datomic (16)
- # docker (13)
- # events (1)
- # figwheel-main (22)
- # fulcro (109)
- # jobs (1)
- # kaocha (8)
- # keechma (1)
- # lambdaisland (5)
- # malli (1)
- # meander (8)
- # mid-cities-meetup (1)
- # off-topic (6)
- # overtone (7)
- # pathom (6)
- # re-frame (2)
- # reitit (9)
- # ring (1)
- # shadow-cljs (92)
- # specter (1)
- # tools-deps (311)
- # xtdb (76)
I'm curious how RELEASE resolves in this maven dep...
{:extra-deps {clj-kondo {:mvn/version "RELEASE"}}
:main-opts ["-m" "clj-kondo.main"]}
Perhaps it's a normal maven feature. Hard to google for "release"!RELEASE (and LATEST) are special "virtual" version numbers that tell Maven to look for the newest released version (non snapshot)
they are officially unsupported by clj (but do kind of work with some big caveats)
big caveat #1 - they break caching and you will never see a new release after the one that it first resolves to unless you -Sforce (or otherwise cause a cache recompute)
at some point, we may actually prevent caching at all if you use these "versions"
subtle caveat #2 - the answer you get is only as good as the metadata index in the repository. for maven or clojars, no worries. if you're using a bespoke s3 repo, then you probably aren't updating the right metadata files and you usually won't see the newest version
generally, I think it's harmless to do this in -Sdeps to grab "latest". it's mildly bad to do it for tools in your deps.edn aliases (like the example here). it's very bad to do it for your project deps.
Does there happen to be an equivalent for git/sha coordinates? That could be quite handy…
Intentionally not, for the same reasons re caching
I guess I don’t understand the caching issue. If you resolve “RELEASE” to a concrete version, and that version happens to exist in the cache already, wouldn’t tools.deps
use it?
(and conversely, if it doesn’t, wouldn’t that version be added to the cache, and thereby eligible for future “cache hits”)
The caching is based on time stamps of deps,edn files. If the file never changes (set to RELEASE), the class path is never recomputed, even if newer versions come out
Caching of classpath (not lib version)
Ah ok. I assume there’s a good reason for making the deps.edn
file the cache key, rather than just recomputing dependencies the classpath every time and having those in the cache?
Recomputing deps starts a second JVM so it’s at least a second, usually more depending on io
This is why clj starts faster than lein usually
It also goes to build repeatability
Or “clj repeatability”
Ok. I’ll assume there’s a good reason for needing a second JVM to do that (not requesting an explanation, btw, unless you’d like to provide one), and understood full well the performance implications of starting a JVM.
it's running a Clojure program with a different classpath the program you're executing
specifically, it's running tools.deps to compute the classpath based on your deps.edn (talking to Maven, maybe S3, maybe Git, etc). in the end it spits out the results in cache. Your actual program is then started with the classpath you intended. Once we've cached that work, we can spit the first part and just run the program.
So the advantage of caching based on the deps.edn
file, rather than the classpath it contains, is all the I/O to talk to Maven, S3, git, etc.?
well, that's all of the work. not much point to caching otherwise
expanding and downloading a full deps tree can easily mean dozens of jars and many megabytes of network traffic (if your m2 and/or git cache is cold)
even if you have all the jars, expanding the tree is more than you'd want to wait, example in tools.deps.alpha repo (~80 jars in the full tree), all jars in cache so no downloads:
amac:tools.deps.alpha alex$ time clj -Sforce -e nil
real 0m3.028s
user 0m12.567s
sys 0m0.756s
amac:tools.deps.alpha alex$ time clj -e nil
real 0m0.745s
user 0m1.647s
sys 0m0.133s
(one caveat here is that the clj uber jar is not currently aot compiled - that's coming soon and will improve that first time, which includes a lot of loading)
but it's still not time anyone wants to wait
with a cold m2 cache, time is about 7.5 s (aot may knock a couple seconds off that)
I can see why that approach will be faster, though it breaks down (cache becomes stale) in the presence of dependencies that are expressed using a “floating” version reference (RELEASE, LATEST, SNAPSHOT, etc.). Those were deprecated in Maven3, and perhaps tools.deps should follow suit and emit a warning when it encounters such a thing?
@deactivateduser10790 My dot-clojure deps.edn
shows how you can resolve the head of the default branch -- in the comments.
And then (load-master 'clojure/tools.trace)
(following the http://github.com URL pattern, not the org.clojure/tools.trace
Maven artifact pattern)
Potentially dumb question, but is it expected that code inside an EDN file would be executed? Or does that rely on a coincidence of how the Clojure EDN reader functions?
@deactivateduser10790 Can you give a specific example?
I mean, EDN can contain tagged literals and you can provide reader functions that process those... but that's not exactly "code inside an EDN file".
edn files are data, not code, and are not evaluated
They are read but that will only construct tagged literals, and clj does not provide a way to install readers for tagged literals
@seancorfield your example includes code (`(require '[clojure.tools.gitlib :as gitlabs]) …`) - how is that code evaluated?
Those are comments showing what you would execute in your REPL...
The files contains lots of comments explaining how to use the aliases, with links to repos.
Oh ok. So I would not put those in a deps.edn
then.
Huh? Those are comments and they are in a deps.edn
file.
Yes they are, and as a result I would expect to uncomment them and have them Just Work:tm: .
I mean, that repo literally is my ~/.clojure/deps.edn
file.
But if I’m following you, you’re saying that’s not correct - that those lines need to be copypasta’ed into a REPL.
Forgive me but I'm a bit shocked you would think code in EDN files would be evaluated...
I didn’t - that’s why I asked the question.
I was quite surprised to see commented out code in an EDN file.
(and by “quite”, I mean “very”…)
Regardless, @alexmiller separately explained that by design you can’t do an equivalent of RELEASE
for git/sha coords in a deps.edn
file.
https://github.com/practicalli/clojure-deps-edn/blob/master/deps.edn contains comments with lots of shell commands, and even some elisp -- you wouldn't expect any of that to be executed just by reading the EDN file, would you?
Why would you assume I’ve read some random deps.edn
file? Sadly I don’t have that much disposable time…
Well, you read my file and came to a ... strange conclusion ... so I offered another example deps.edn
and wondered what conclusion you would come to from that...
If you re-read my original question (https://clojurians.slack.com/archives/C6QH853H8/p1595913713054800), you might see why I was assuming a deps.edn
-only solution, and therefore didn’t understand your non-`deps.edn` answer.
In general, answering questions people didn’t ask is a wonderful source of confusion. 😉
With the Clojure CLI/`deps.edn` the "equivalent" to Maven/Leiningen/etc is often "some code that you run" -- which seemed like an acceptable answer to your question.
That's why I was so puzzled by your follow-up question, as it seemed unrelated to my answer (I was thinking "No, of course reading EDN won't execute code!").
I guess I should add "Here's some code you can run in your REPL" to my deps.edn
file where there are code examples 🙂
That would have avoided any confusion, no doubt. 😉
It is sometimes so hard to predict your audience's state of mind 😆 (when writing documentation, I should add).
Professional technical writing is such an under-appreciated skill, I’ve found.
Hey guys. If i have a setup as described in https://clojure.org/guides/deps_and_cli#_using_local_libraries. is there a way to fire up a repl in the hello project which reloads the time-lib deps if they are changed?
no, that's not a built-in feature of Clojure (or Java). there are ways to do some variants of this but it's not common
well, do you mean local dir or local jar?
if local dir, you can just use Clojure's normal :reload or :reload-all mechanism built into require
yeah, so that's just normal reloading
any idea why running brew upgrade clojure/tools/clojure
installs 1.10.1.561 not 1.10.1.590 ?
561 is the newest stable release
Following up from my comment in the announce thread:
{:paths [:clj-paths :resource-paths]
:aliases
{:clj-paths ["src/clj" "src/cljc"]
:resource-paths ["resources"]}}
Is that correct, or should :clj-paths
and :resource-paths
be underneath an alias?If that is correct, I don't see the value since they are fixed labels and values -- am I missing something @alexmiller?
oh, that is right - they are aliases
an alias is just a name for some data
this was the original meaning here but we have kind of gotten off talking about things that way by tying it into clj's usage of alias data to affect classpath construction
OK, so how is that useful since they are just fixed values?
at the moment, it's not very useful
Also, you have this paragraph twice "Replace project environment ("tool")" -- one with plenty of detail, one with very little.
that's actually intentional - the first part is kind of an overview, and the second is more how the tool works with more detail
doing a lot of heavy editing on this page lately but will likely change more over time
OK, I think it's just really confusing at the moment with two identical headers...
I'm ok with that for the moment :)
the toc at the top side bar may make the structure more evident
I've gone through about 5 different structures for this page recently, and I don't think I'm done
On another wordsmithing issue: now that page refers to "tool" as something that might want to override :deps
and/or :paths
, this section name might be confusing (a different meaning of tools
) https://clojure.org/reference/deps_and_cli#_clojure_tools_usage
yeah, I've been fighting that, haven't decided what to do about it yet
not enough words :)
it's like naming things is hard
Tools are just so useful 🙂
but if you had say, a build tool that wanted to also use a subset of paths it might be useful
The Maven install example is missing an alias tho' (even if the paths one isn't), yes?
{:aliases
{:fn clojure.tools.deps.alpha.install/install
;; :args map could be provided but can pass on command line instead
}}
That's meant to be executed with -X:some-alias
(most people will pick -X:install
I suspect)
ah, yes that is
I actually saw that late last night and forgot to fix
I'm curious as to why that ability surfaced as a built-in option, given that JAR files can already be used as :local/root
deps?
it's not a built-in option, it's a built-in program
didn't seem big enough to make into its own thing, depended heavily on all the code in tools.deps, wanted it for dev-local, etc
Interesting...
serves as a good example :)
the plan is to shift some of the magic switches in clj over to just be programs you can -X
some of those might become built-in to the root deps.edn, not sure yet
The install line you gave in the announcement doesn't seem to work
Error: No available formula with the name "clojure/tools/[email protected]"
==> Searching for a previously deleted formula (in the last month)...
Error: No previously deleted formula found.
==> Searching for similarly named formulae...
Error: No similarly named formulae found.
That's from brew install clojure/tools/[email protected]
(after a brew uninstall clojure
)
Should be 1.10.1.590
Ah, shoot
wow need to get my head around these new tools.deps features; they might make some stuff I’ve been planning to do completely redundant :thinking_face:
how is the -T
alias different to having an alias with a :deps
key?
I need to figure out how to get the clojure
script updated on a couple of our older servers since this would help eliminate some of the extra script stuff we've written (but I think there's a blocker for installing clojure
on a couple of our old servers).
It is exactly what was already there via -A, just has its own switch now
ok so it just makes the intent clearer on the command line?
A is meant to be an “all” kind of thing but this didn’t have its own name, so now it does
so what would -T
do with :extra-deps
instead of :deps
?
(Which also helped further clarify some things in the code which has gone through some substantial changes)
wow I had no idea how many deps had unqualified names. I thought it was just a handful, but it’s way more than I expected
Each of the sub processes takes what it expects and ignores the rest, like all good Clojure programs :)
Should this check include tools_aliases
now?
-h|--help|"-?")
if [[ ${#main_aliases[@]} -gt 0 ]] || [[ ${#all_aliases[@]} -gt 0 ]]; then
break
else
help=true
shift
fi
;;
Maybe I'm just missing the actual flow of the script then, nm.
Yeah this has to do with falsely interpreting a -h appended to main aliases as a help opt
(I was just grepping for (tool|all).alias
through the new script out of curiosity)
Would be curious if you try the win install :)
@alexmiller re: -h
-- that means that clojure -A:test:runner -h
and clojure -T:test:runner -h
behave differently.
(! 1537)-> clojure -T:test:runner -h|more
Version: 1.10.1.590
...
(! 1538)-> clojure -A:test:runner -h|more
Unknown option: "-h"
Wasn't sure whether that was intentional or not since you said -T
and -A
were "the same"?(the first case displays help -- -h
is not passed to the main program; the second case passes -h
to the main program in the test runner here)
this is kind of a corner case - the condition is guarding against having -A/-M supplying the first part of the main args and then -h on the command line where it is not actually the main args to pass to clojure.main. I'm not worried about it.
Fair enough. Just wanted to point out that it is a difference between -A
and -T
🙂
there's no difference in how :deps and :paths work, which is what I meant
Just tried doing -X:myfn
in one of my projects and I get the error:
clojure -X:myfn
Execution error (FileNotFoundException) at clojure.main/main (main.java:40).
Could not locate clojure/tools/deps/alpha/exec__init.class, clojure/tools/deps/alpha/exec.clj or clojure/tools/deps/alpha/exec.cljc on classpath.
are you on clj 1.10.1.590?
I thought I was
$ clojure --help
Version: 1.10.1.590
...
I get that too, also on 1.10.1.590:
(! 974)-> clj -Sdescribe
{:version "1.10.1.590"
:config-files ["/usr/local/Cellar/[email protected]/1.10.1.590/deps.edn" "/Users/sean/.clojure/deps.edn" "deps.edn" ]
:config-user "/Users/sean/.clojure/deps.edn"
:config-project "deps.edn"
:install-dir "/usr/local/Cellar/[email protected]/1.10.1.590"
...
(! 975)-> clj -X:example
Execution error (FileNotFoundException) at clojure.main/main (main.java:40).
Could not locate clojure/tools/deps/alpha/exec__init.class, clojure/tools/deps/alpha/exec.clj or clojure/tools/deps/alpha/exec.cljc on classpath.
Full report at:
/var/folders/p1/30gnjddx6p193frh670pl8nh0000gn/T/clojure-13599808261801984368.edn
(! 976)-> cat deps.edn
{:aliases
{:example
{:fn clojure.core/println
:args {:n 1}}}}
(! 977)->
if you clj -Sdescribe
and then jar tf <the-install-dir/clojure-tools-1.10.1.590.jar | grep exec.clj
do you see it?
what installer are you using?
the jar is further down than that in /usr/local/Cellar/[email protected]/1.10.1.590/libexec/clojure-tools-1.10.1.590.jar
sorry, bad multi copy/paste on my part, that's right
exec.clj is in there yes
this is mac? linux?
$ jar tf /usr/local/Cellar/[email protected]/1.10.1.590/libexec/clojure-tools-1.10.1.590.jar | grep exec.clj
clojure/tools/deps/alpha/exec.clj
(yup, same here)
brew was the installer
clj -Sdeps '{:aliases {:myfn {:fn clojure.core/pr}}}' -X:myfn
is a standalone example
edn is broken
Fails for me
edn is broken means?
ah wait sorry was in a project with a broken edn file
(! 982)-> clj -Sdeps '{:aliases {:myfn {:fn clojure.core/pr}}}' -X:myfn
Execution error (FileNotFoundException) at clojure.main/main (main.java:40).
Could not locate clojure/tools/deps/alpha/exec__init.class, clojure/tools/deps/alpha/exec.clj or clojure/tools/deps/alpha/exec.cljc on classpath.
Full report at:
/var/folders/p1/30gnjddx6p193frh670pl8nh0000gn/T/clojure-12219293780956477884.edn
ah, I was able to repro
$ clj -Sdeps '{:aliases {:myfn {:fn clojure.core/pr}}}' -X:myfn
Execution error (FileNotFoundException) at clojure.main/main (main.java:40).
Could not locate clojure/tools/deps/alpha/exec__init.class, clojure/tools/deps/alpha/exec.clj or clojure/tools/deps/alpha/exec.cljc on classpath.
Full report at:
/var/folders/ln/536xqskd3_g80n5pdbsjkrjw0000gn/T/clojure-8308868078358895829.edn
it matters whether you're in a directory with a deps.edn
well, that's definitely a bug :)
Crashes for me whether there's a deps.edn
file or not.
yeah same
hm, maybe it's a cached classpath for me or something
I tried it via an alias in a deps.edn
file (shown above), then tried via the command line with just {}
in deps.edn
, and then tried in a directory with no deps.edn
-- all of them crash the same way. Even tried -Sforce
and it still failed.
I tried two of those; just tried with -Sforce too — and same
well, that's weird. :) I've been using this for a while and others have tested it as well, somehow never saw an error
I'm sure it will make sense when I understand why it's doing it ... this is why it's a dev release!
-X has to go at the end, in case that affects anything you tried
nope, I had -X
as my only alias
Well I’d be happy to try and help narrow debug it but I’m afraid I need to call it an evening 😞 I’ll check back here tomorrow. Thanks for your help, and also thanks for the feature… it looks like it’ll be really useful.
ah, this makes sense to me now, and why it worked for me
and why things others tried worked. such a combination of coincidences... anyhow will fix
Now I'm curious, what's the bug?
it's not putting that class on the classpath, obviously :)
I was testing in the tools.deps.alpha repository itself
where it is
and others were testing things that used the install program, which requires you to pull in tools.deps.alpha
so those all worked
I may actually have flubbed a merge somewhere
@seancorfield @rickmoynihan ok, new clj 1.10.1.596 is available, should fix this
works now! Thanks 🙂
Looks fixed! Thank you!
if you try it on windows (or linux), would be happy to hear there too
@vlaaad If you want to get strings from the command line in your -X
-executed function, you can always use *command-line-arg*
(although you'd have to discard leading arguments passed to the CLI itself I guess)
(! 1010)-> clj -A:test -X:example :test value
("-X:example" ":test" "value") ({:test value})
Looks like you'd only have to skip over the first arg?How would you want the CLI to distinguish between "I want this as a string" vs "I want this as an EDN value"?
It seems like you'd have to try
to read as EDN and if you got an error or a symbol then use the whole argument as a string, else whatever the EDN reader produced? Which is open to all sorts of surprises I would expect...?
I don't want to deal with escaping because I use both powershell and bash that have different escaping rules. With those, whenever I have a need to escape I wish I just used a file. This might be a bit too limiting for convenience, but I'd be fine with this: everything that can be read as number/boolean/keyword/nil -> number/boolean/keyword/nil everything else, including things that can be read as collections -> string
I've been thinking a bit more about simple vs easy, and currently I think I'm overreacting, I think escaping might be an okay price to pay for the limitations different approaches provide
when you have static data, the best thing to do is put it in deps.edn and reference via alias
> including things that can be read as collections -> string I think that's a bad idea since it's common to want to pass a map of stuff when calling Clojure function (in general) so that choice would force EDN parsing on everyone
with -X you are always passing a map - the command line is overrides to the data in deps.edn
and the overrides support nested paths
Right, I meant as one of the arguments (inside that map)
nested paths gets you out of another set of cases
i.e., to produce a nested map
Yeah, having :test 1234
and :test [1234 5678]
produce a number and a string respectively would be very strange.
it turns out vectors are actually ok bash if you use the comma
:test [1234,5678]
is actually ok
I sympathize with the additional pain on PS (I too use it from time to time with the Clojure CLI) but since the vast majority of Clojure CLI users are on macOS/Linux I'd rather not make all their lives more painful, just to make PS less painful -- and it's already a bit painful to use for the Clojure CLI...
maybe this is a topic for #clj-on-windows but what's the story on the new Windows terminal?
and clj -X:example [:test,:value] 1234
works on macOS so, yay, portability! 🙂
@alexmiller The new Windows terminal is just a fancy tabbed shell around existing PS, cmd, and Linux terminals.
so nothing new
out of curiosity, why are unqualified lib names now deprecated? was there a deeper issue that needed addressing or is it just because qualified names are unambiguous and more correct?
I saw it in the blog post that he posted https://insideclojure.org/2020/07/28/clj-exec/
which mentioned the deprecation again, but I was curious if there was a deeper reason for it
And discourage hiccup/hiccup in favor of com.weavejester/hiccup. But in a general sense, not the global sense.
Finally 🙂 That was one thing that always made me wonder why one would have unqualified library names when clojure is so heavily rooted in java.
not sure what I can add beyond what's in the blog
unqualified names are bad so we're going to stop encouraging them in this area
PS C:\Users\Vlaaad\Projects\tdeps> cat .\deps.edn
{:aliases {:prn {:fn clojure.core/prn}}}
PS C:\Users\Vlaaad\Projects\tdeps> clj -Sdescribe
{:version "1.10.1.596"
..."}
PS C:\Users\Vlaaad\Projects\tdeps> clj -X:prn
Execution error (FileNotFoundException) at clojure.main/main (main.java:40).
Could not locate clojure/tools/deps/alpha/exec__init.class, clojure/tools/deps/alpha/exec.clj or clojure/tools/deps/alpha/exec.cljc on classpath.
hrm, let me check on that, shouldn't be using that class anymore
-Spath is
C:\Users\Vlaaad\.m2\repository\org\clojure\clojure\1.10.1\clojure-1.10.1.jar;C:\Users\Vlaaad\.m2\repository\org\clojure\spec.alpha\0.2.176\spec.alpha-0.2.176.jar;C:\Users\Vlaaad\.m2\repository\org\clojure\core.specs.alpha\0.2.44\core.specs.alpha-0.2.44.jar;src
`path is fine, it's the class, I missed one change there
windows 1.10.1.600 has the fix
depends what you want to compose with :)
with other -X, no
with all the classpath stuff, yes
but if you want to run multiple things, write a program that does so and run it with -X :)
I don't want to write lots of programs! I want to change my programs on a whim at the cli. Start a socket server, start a whatever, run the program in the local project that does setup, run my custom dev function.
(We've discussed before though, not really trying to convince, but I hoped that exec would provide this)
Right now I'm (ab)using the fact you can supply an init and a main to load a dev.clj in my home directory, which will run things based on the directory the jvm started in...
there's this thing called a repl that lets you do like ... anything
PS C:\Users\Vlaaad\Projects\tdeps> clj -Sdescribe
{:version "1.10.1.600" ...}
PS C:\Users\Vlaaad\Projects\tdeps> clj -X:prn
Execution error (ExceptionInfo) at clj-exec/check-first (clj_exec.clj:32).
Invalid first arg to exec: prn
could it be PS escaping away the :
? :thinking_face: other args like -A:alias
work fine thogh
will take a look, not sure
maybe I'm missing the first arg I match in the pwsh for this, but seems like we'd get nothing here, not part of the arg
how hard is it for you to just modify the ClojureTools.psm1 ?
I think line 84 just needs to be $ExecAlias += $arg, $params
it's losing the matching $arg right now
I tried what you suggested, now clj "-X:prn" :a 1
succeeds, while clj -X:prn :a 1
still fails with error Invalid token: :
hacked it to work with this:
$sym, $params = $params
$ExecAlias += "$arg$sym", $params
now it doesn't work with "-X:prn" thoughhmm, that works:
s> clj -A: beep:boop:bap
WARNING: Specified aliases are undeclared: [:beep :boop :bap]
Clojure 1.10.1
user=>
is there a difference in powershell parsing a single thing (into leading char / remaining char) or many things?
no, I mean are we getting different behavior on clj -X:foo
vs clj -X:foo :a 1
?
no:
PS C:\Users\Vlaaad\Projects\tdeps> clj -X:prn :a 1
{:a 1}
PS C:\Users\Vlaaad\Projects\tdeps> clj -X:prn
nil
but this wont work: clj "-X:prn"
, because I made the script to expect args -X:
and prn
separately
so what we really need to do is accept both -X:alias
and -X:
, alias
for powershell to make it predictable
if ($arg -eq "-X:") {
$sym, $params = $params
$ExecAlias += "$arg$sym", $params
} else {
$ExecAlias += $arg, $params
}
PS C:\Users\Vlaaad\Projects\tdeps> clj "-X:prn" :a 1
{:a 1}
PS C:\Users\Vlaaad\Projects\tdeps> clj "-X:prn"
nil
PS C:\Users\Vlaaad\Projects\tdeps> clj -X:prn
nil
PS C:\Users\Vlaaad\Projects\tdeps> clj -X:prn :a 1
{:a 1}
the code for other aliases in tools.deps is actually tolerant of the split here, maybe that's necessary for the -X stuff too. in other words, we've been masking this problem
In earnest, there's a little bit of a desire to hide implementation behind flags. Telling someone to run clojure -A:nrepl:piggieback
is easier than explaining that they need to run a set of functions once waiting for the repl to connect, and then press buttons on their editor, in an exact sequence to make it work.
Right now I use jvm options.
Dang, we use a lot of single-segment lib names at work! 😞
(updating 27 deps.edn
files in our monorepo!)
feedback on the warning message? I tried to make it useful
It's perfect.
Annoying, but perfect.
The only slightly weird thing was that I seemed to get all of the warnings twice?
that dimly rings a bell. I wrote this like a month ago. I think because it's encountered during canonicalization and also during expansion or something?
I have https://www.youtube.com/watch?v=jsW9MlYu31g running through my head ...
Am I right in thinking the new "alias data" feature is going to allow people to add all sorts of configuration stuff into deps.edn
as data under an alias?
if they like
Folks have been asking for that for quite a while 🙂
like most things, taste is helpful
(and have been told in the past, "don't do that" 🙂 )
it might be a good place to put like, build configuration
Hmm, and because aliases don't compose, it's "just" fixed data so I guess that's a nice place to draw the line.
I suspect shadow-cljs and other tools might leverage it for build config to avoid having a separate file for that...
btw, I don't know if add-libs works with latest (haven't tried). I am still injecting the lib map atm which is what add-libs works starts from, but not sure if it also uses anything else in tools.deps that's changed. the branch I have has the stuff to switch to basis but also other stuff too so some interpolation will need to be done, not sure when I'll get to that
NP. I just updated my dot-clojure deps.edn
to rename the alias from :deps
to :add-lib
and add notes that it should be considered experimental and likely to break or go away 🙂
(I had forgotten that the installed deps.edn
contains a :deps
alias when I originally added it)
I also just cleaned up the :rebl
* aliases to reflect the latest REBL having its own deps.edn
files for java8
and openjfx15ea
(plus some reorganization and updating several versions).
My work is now finally using deps.edn/tools.deps/clojure CLI (how do you even call this stuff?). I moved out our front-end build to it (using figwheel.main / cljs.main) last week while we still do the uberjar and REPL stuff with boot. Also now we can finally run Java 11 everywhere, since we were stuck, the boot frontend stuff didn't work with it (at least not for us).
Also we use this dev script to start 3 processes simultaneously: clojure -A:cljs/dev
, clojure -A:less/dev
and ./boot dev
, while having only one terminal tab open:
https://gist.github.com/borkdude/8f5dff7c2330ca520403eb44c9013a83, just as a convenience
3 jvms! I bet that doesn't integrate well with cider jack in. Might I suggest starting 3 threads instead?
I've always avoided cider-jack-in, I always use cider-connect. Even more so now I'm developing on a remote machine but editing files in my local emacs using tramp.
Threads may work but it's not a huge deal right now. We need at least two JVMs given we're using two different build/classpath/dependency tools right now.
As part of this monorepo deps cleanup I'm doing (to prevent all those DEPRECATED warnings!) I'm also removing the last few references to nREPL in our setup since neither I nor my team mate use that now.
I’m curious why the new tools.deps adds a tool to do local maven installs. Is this something people frequently need? I’ve probably only ever needed to install free form jars into my local maven repo a few times in the past ten years. I mean sure if I’ve built a jar myself I will frequently want to install it, but it seems strange to supply a method to install jars, but not build them. I’m just curious what problem it’s solving for people.
Am I missing something in my workflow; or is it just that this happens to have been baked before other build tasks in tools.build?
Perhaps related to Datomic's dev-local needing to be installed into your local Maven repo to be used (it's not distributable).
^ That is what Alex said when asked earlier @rickmoynihan
ahh ok makes sense in that use case. Thanks @seancorfield
@alexmiller Robot Chicken has some pretty darned funny riffs on Star Wars scenes, including the one you linked above: https://www.youtube.com/watch?v=WpE_xMRiCLE