This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-05-04
Channels
- # announcements (4)
- # aws (3)
- # babashka (58)
- # beginners (59)
- # biff (6)
- # cider (3)
- # clj-kondo (48)
- # clj-on-windows (1)
- # cljdoc (1)
- # clojure (136)
- # clojure-europe (19)
- # clojure-gamedev (7)
- # clojure-germany (2)
- # clojure-nl (7)
- # clojure-norway (1)
- # clojure-portugal (1)
- # clojure-uk (4)
- # clojurescript (41)
- # community-development (2)
- # core-async (5)
- # cursive (10)
- # data-oriented-programming (1)
- # data-science (1)
- # datahike (5)
- # datomic (60)
- # docker (2)
- # emacs (13)
- # figwheel-main (19)
- # fulcro (12)
- # graalvm (9)
- # holy-lambda (41)
- # honeysql (14)
- # introduce-yourself (3)
- # jobs (4)
- # lsp (11)
- # nrepl (1)
- # off-topic (9)
- # other-languages (2)
- # pathom (22)
- # portal (5)
- # re-frame (17)
- # remote-jobs (4)
- # reveal (14)
- # shadow-cljs (1)
- # tools-build (7)
- # tools-deps (47)
- # xtdb (8)
- # yada (2)
How do I import this library in my deps.edn
? https://mvnrepository.com/artifact/io.github.mightguy/symspell/6.6.154
There is a Leningen example but it says [io.github.mightguy/symspell "6.6.154" :extension "pom"]
and I have no idea what to do about the :extension "pom"
part. Converting it to io.github.mightguy/symspell {:mvn/version "6.6.154"}
doesnβt seem to work.
Yes, it is. I've done some of the internal work for this but still more to do
(I wrote io.github.mightguy/symspell-lib {:mvn/version "6.6.154"}
as that was referenced elsewhere and this seemed to work)
Hey everyone! Has anyone noticed with Clojure 1.11+ that their deps aren't fetching when they try and run things from the Clojure CLI now? I have to run the exact command with -P
then run it again without which is proving REALLY awkward with wrapped tools like Kaocha. This is happening across all projects of mine, so it's in the Clojure CLI install rather than the projects themselves. The only thing that changed (I think) was the Clojure CLI version updating from 1.10 to 1.11+. Has something changed in the CLI contract and now we need to remember to fetch these deps? Is this a bug? Misconfiguration on my part somehow?
No intentional change that I can think of
If you have something reproducible, happy to look at it
What do you actually see when you run?
Hmm, well it seemed like if I ran clj
or used a jack-in it would try to start my Clojure projects without fetching the dependencies they required (when it definitely used to!).
I did delete my .m2 recently, so maybe the .cpcache also needs clearing per dir? :thinking_face:
I just tried it in a blank directory and it fetched the dependency! So I'd put it down to .m2/.cpcache interplay (if that's possible?) or the arguments we pass to clj
now have it skip fetching deps since we have some combination of -A -M...
If you have a cpcache, and you have the same command, it won't fetch anything
If you alter the m2, you'll need to either erase the cpcache or use -Sforce to force a redownload of the deps
Got it! I feel like I haven't noticed this before and it used to still fetch everything even if I wiped my .m2, but maybe I just got lucky or accidentally fixed it. Thanks for the insight / prompting me to think about it more!
It has always worked like this
by not deleting your m2?
Oh no, I've cleared that many many times, mostly around where I mounted it into docker containers which ends up creating the files under root which complicates other things. (I should work around that by keeping a separate root .m2 from my user really) I guess I remembered to remove my .cpcache in the past and it slipped from my memory.
I don't think so if you don't need to. As I mentioned higher up in the thread, I did it because I'd been mounting my .m2 into docker containers which poisons it with root owned files. I could chown them too, but I'm being lazy and silly. The only reason I'd recommend it is if you were REALLY tight on disk space, your .m2 was huge and you know you're only working with a few JVM deps now so you won't need to redownload them all.
That way you clear out old versions of deps you no longer use and redownload the ones you need. But as I've found, you must delete your .cpcache directories in your projects to ensure it'll re-fetch dependencies.
You can also use -Sforce to force recompute of the classpath (and download if needed)
Are there command line tools (or REPL based tools) to help find the full name of a library to add as a dependency?
I can find versions of libraries using the built-in clojure -X:deps find-versions :lib fully-qualified/library-name
, which works very nicely assuming I know the correct library name, but that is the bit I'd like a tool for.
I have been using https://github.com/hagmonk/find-deps although that seemed to stop working. I forked it and got it working and fixed some of the deprecation warnings (which I'll send a PR for, although I think some of the dependency versions in that project also need updating, so may need to hack a bit more)
Any alternative CLI tool suggestions are welcome (otherwise I'll try find some time to improve find-deps).
Running find-deps I was getting a very strange warning
Error building classpath. Manifest type not detected when finding deps for swisseph/swisseph in coordinate #:loca
01/swisseph-2.01.00-01.jar"}
Changing to a different directory fixed the issue, so I assume it was some kind of cache issue. I couldnt find that library in the dependency tree for find-deps or online. Very strange.There's some speculative work on dep searching in the add-libs3 branch of tools.deps, but it's pretty fiddly, not sure it will ever be integrated
Given that the Maven coordinates can be arbitrarily different to the namespaces within a library, I don't see how that could work, short of indexing the whole of Clojars (and a lot of Maven Central)?
search apps exist
the code in that branch uses them (http://mvnrepository.com, http://grep.app, etc)
OK, and they're essentially brute force searches? (I know "go read the code" π )
https://github.com/clojure/tools.deps.alpha/blob/add-lib3/src/main/clojure/clojure/tools/deps/alpha/repl.clj#L109 onward -- @U05254DQM
I need something akin to :prep-tasks
for lein's uberjar
. Basically, some scripts (esp. front-end related - shadow-cljs, etc.) generate a bunch of throwaway files and I need to clean them up before packaging.
What's the recommended way of dealing with that? A custom alias that calls a function to clean them up?
I'm using {uberdeps/uberdeps {:mvn/version "1.1.4"}}
for packaging; I don't know if that's relevant
@ag Do you have a build.clj
file?
I do pretty much all my testing/packaging via tools.build
these days and then tasks are "just code" so they can do whatever you need.
https://clojure.github.io/tools.build/clojure.tools.build.api.html#var-delete π
Oh, that's interesting. I did not know about this. Still new to deps.edn stuff, been stuck with Leiningen until very recently. I'll try to learn about this. Thank you!
@ag https://clojure.org/guides/tools_build the guide shows some examples of builds as ordinary programs
it's not possible to re-use keys from one alias in another, right? e.g, I have alias :dev
that adds extra-paths and deps, if I want to use the same stuff in other alias, e.g. :test
, I'd have to repeatedly declare those, correct?
clojure -A:dev:test
?
Or if it's a subset of :dev
that you need for :test
, split :dev
in two.
@ag This is typically how I start my main dev REPL for work: SOCKET_REPL_PORT=5000 clojure -J-Dlog4j2.configurationFile=log4j2-sean.properties -M:rebel:portal:everything:dev:test:runner:build:dev/repl
but sometimes I add even more aliases (such as :reflect:jedi-time:add-libs
π )
Yes, I know I can chain aliases, but that means some of them won't work without others. If that's accepted, I'm okay with that, I guess.
@ag https://clojure.atlassian.net/browse/TDEPS-170 and https://clojure.atlassian.net/browse/TDEPS-220 are relevant here
And https://ask.clojure.org/index.php/10564/specify-an-alias-that-is-a-set-of-other-aliases (linked from the second jira issue) if you'd like to leave an upvote π
hmm aliases that depend on aliases might be neat
well don't get too attached to this particular solution, the problem is about composition and interacts with other problems