i see the typo now. ugh. I should turn on a spell check before i post something to catch things like this.
On latest clj, you'll get: Error building classpath. No :mvn/version specified for com.datomic/ion
Now that add-lib isn't functional, if I wanted to load dependencies for a particular function call with exec-opts (without the user having to know which dependencies to add to deps.edn for that call) how would I do that? I want to provide some beginner tools as part of something, but I don't want to bloat the primary use case. If I had bash-style exec, I'd probably just restart the jvm that way. I want the set of functionality to be an open-set though, so it might expand in the future, and the user shouldn't need to fiddle around to get that working. I'm certainly aiming for "easy" here.
Just looked at what ion does, that has ion-dev which you install in your user deps.edn, that strikes me as an odd choice.
Good morning, does anyone use CircleCI with tools-deps and have an example I can see? I'm just exploring a few alternatives to our Jenkins. I use Github actions on my own stuff (e.g., https://github.com/eamonnsullivan/github-pr-lib I create for scripts and deploy to clojars) and I'm also going to take a look at AWS CodeBuild/Pipeline, but examples to study are mostly lien-based.
@eamonn.sullivan Almost all of my projects do
So, just to finish this thread off, in case anyone is still reading: I did eventually get it to work, providing the same functionality that I have (on other repos) using Github Actions, which was the goal. Thanks very much for the help and the pointers! https://github.com/eamonnsullivan/github-api-lib/blob/main/.circleci/config.yml
Thanks for sharing
Ah, perfect. Thank you!
https://github.com/borkdude/clj-kondo/blob/master/.circleci/config.yml
@eamonn.sullivan There are images you can choose from that already have Clojure CLI tools included. http://practicalli.github.io/clojure/testing/integration-testing/circle-ci/ If you want the very latest version of Clojure CLI tools, then use Borkdude's approach (which I am going to add to that page I mentioned right now, as I want to use 1.10.1.727)
@eamonn.sullivan I have a collection of different approaches I'm going through in this ticket https://github.com/practicalli/clojure-content/issues/183 Would be interested to hear what you end up using. Thank you.
I suppose this could be considered the ability to import deps.edn aliases into your project somehow :)
Hum, I think there's a mistake in exec.clj. https://github.com/clojure/brew-install/blob/f734dacaab43c0cd44c5ffffb8fa3a10ab64d4a0/src/main/clojure/clojure/run/exec.clj#L20 this throws, but almost all calls also throw, https://github.com/clojure/brew-install/blob/f734dacaab43c0cd44c5ffffb8fa3a10ab64d4a0/src/main/clojure/clojure/run/exec.clj#L26
What is the recommended way to deploy a jar to a private S3 repo using tools.deps?
Putting ion-dev in user deps.edn is recommended - itβs a general tool for deploying ions
We will be updating add-lib to work again btw with some additional apis and ultimately in master
But not sure I have a good answer for this use case right now
Yeah that doesnβt look right
I also noticed that read-args
uses a loop but could be mapv
quite easily
np. Maybe I'll start with bloat, then swap to add-lib later.
fixed the double throw
agreed on read-args - that stuff has been through a lot of versions where the positionality was more important, going to leave it for now as it's reasonably likely to go through more changes
This seems like an argument against exec-opts to me: clj -X:user/new create :template "\"$PWD/template::new-app\"" :name my.project.name
(this doesn't work for me, but that's unrelated, just the awkward way to pass in pwd)
what doesn't work?
and it's awkward because? quoting?
@alexmiller I'm currently working on a main which will have exec-like uses, particularly the notion of updating a map in response to those args. Might be useful to rely on the exec code once it's stable. Then I can just point at your docs :p
Obviously read-args is pretty simple, and so is the reduce itself. So maybe that's not really useful. But I'm not sure how it'll evolve. The tagged-literal reader might be subtle.
I would not rely on the exec code right now - I do not (yet) consider that to be "public api"
@alexmiller yeah, the quoting is awkward, compare to main-style:
--template "$PWD/template::new-app"
Doesn't work because I'm passing wrong args to clj-new, but I didn't need that debugging.I think it would actually be useful to move some or all of it into clojure itself (similar to clojure.main) but that's probably longer term
Yeah, I saw it was all private and ducked out :)
I built a version locally, using Maven, based on a t.d.a add-lib branch a while back I think. Whatever was the equivalent of 0.8.667 it seems.
I built it on April 6th, so it's probably the head of the add-lib
branch, which was 0.8.667 plus the calc-basis stuff, looking at the commit logs. @dominicm I guess keeping your own version around for this isn't going to work for your use case?
@seancorfield it would yeah, I had assumed that stuff was completely broken by the internal changes. I'll give it a go, thanks!
@dominicm an FYI on usability there: both clj-new
and depstar
ended up allowing symbols or strings in most argument slots because of quoting so :template foo
works because it is silently converting the symbol to a string behind the scenes. But of course you can't use symbols in all cases (and particularly yours).
-rw-r--r-- 1 sean admin 58110 Apr 6 2020 tools.deps.alpha-0.8.667-add-lib.jar
In case you want a sanity check on the size of the JAR after you build it. Then I just use :local/root
to depend on the JAR.@seancorfield heh, that feels like a dangerous path with spaces and backslashes, etc.
I wonder if a directory named "4" would work, for example
Yup, it only works for "strings" that could be legal Clojure symbols... No, because that would be read as a number, not a symbol.
Even my example is dangerous because it doesn't escape backslashes.
Seems like you wouldn't want to script anything on that basis then.
I suspect you could use Oops, no, that doesn't work. Just symbols and strings then.:4
-- I think both clj-new
and depstar
would work with keywords too since they just call name
on the argument...
I'll probably have to deploy it somewhere, but that's fine :)
(because I just call str
on it -- I thought I was being fancier than that)
Str on a number works I guess?
Anyway. Not a problem/solution situation really. Just an observation that this decision had this property. I'm sure eventually we'll know when to apply each decision (or find a new decision) to get desired properties.
Yeah, that's why I crossed that out. I tried :4
as one of the args and got the equivalent of ":4"
π Much depends on whether you want a plain string or, ultimately, a qualified symbol or relative path or...
I can't find how to do clj -m app.main
in "modern #tools-deps
clj -M -m app.main
, I believe
correct
just wait till we get to post-modern clj
I just pushed an add-lib3 branch that's up to date with master
can I stay using clj -m app.main
on my deploy/scripts?
note that add-lib is now add-libs and there are some other additional apis (not final) in there too - find-revs
and find-lib
in post-modern clj there is no one big story of arguments, but lots of different forks of clj where everyone does their own thing
no one believes that hammock time eventually leads to the ultimate truth anymore. instead writing clojure programs becomes an expression of doubt
:P
also, at some point in the past I made it degrade gracefully if it doesn't have the compiled s3 class stuff so it's a little easier to hack onto a classpath like it was originally
I haven't released stable software since spec-ulation
so hasn't core maybe? I should check
for now, yes (eventually that will stop working but not soon)
1.10.1 :)
Great, I guess I know what I'm doing tomorrow then!
When i start an nrepl server through cider and eval datomic.client.api/client
it complains about missing hmc auth. Indeed, if i check my cider-classpath that dep is missing.
The issue is the same as discussed here: https://clojurians-log.clojureverse.org/datomic/2020-07-22, which the solution being to update clojure. I updated via linuxbrew and now my version of clojure tools is 1.10.1.727. The issue remains.
My only idea is that if i ask cider to desribe the connection it says clojure is on 1.10.1 not 1.10.1.727 i'm not sure if its truncating or if it somehow connecting to an old version
My goal is that beginners can do (require 'beginner)
or something, and it'll go ahead and fetch tools like spyscope and dot-clojure2 for them, and load them up.
Perfect compromise between beginners and advanced users (who will set that stuff up for themselves eventually)
727 is the version of the clojure tools. the actual clojure version really is 1.10.1
(unobviously, any version of the clojure tools can use any version of clojure - the clojure tools part really just tells you what it was built with and what version of clojure you get by default if you don't specify one)
β― clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.0.0"}}}'
Downloading: org/clojure/clojure/1.0.0/clojure-1.0.0.pom from central
Downloading: org/clojure/clojure/1.0.0/clojure-1.0.0.jar from central
Clojure 1.0.0-
user=> *clojure-version*
{:major 1, :minor 0, :incremental 0, :qualifier ""}
user=>
possible the erroneous classpath computed by an older tools deps is cached? just delete the cache?
or use -Sforce
I deleted .cpcache (which i assume is the only cache) and it didn't work. I tried -Sforce, which starts a repl but then I can't connect to it with cider. I just get a "connection failed". I'm going to try restarting my computer and assume this is a cider thing. Thanks for the suggestions.
its not CIDER. and restarting the computer won't clear the cache that is suspected to be at issue (if we are correct)
.cpcache is the classpath cache so sounds like you've done that already
oh wow. i totally glossed right over that message. sorry
oh that hmac auth thing was actually a tools deps bug and should be fixed in latest
I wonder if there's 2 copies of clojure in $PATH or something...
yeah, can you repro outside cider?
if not, I'd guess you're somehow seeing a different version of clojure, or something is explicitly using an older version of tools.deps.alpha
cider literally just runs clojure -Sdeps '{nrepl/nrepl β¦ cider/cider-nrepl β¦}' -m nrepl.cmdline β¦
cider does just run clojure -Sdeps, but ill try using it directly just in case.
cider's jack-in isn't magic, it's just saving you knowing which dep & which main to start.
(and now prints that and optionally the cljs startup to remove any semblance of magic)
The issue was corrected by having cider look at a version of clojure tools that had the bug fix. I had two versions of clojure installed (no useful reason for that). So i uninstalled both and reinstalled using linux brew. As dominicm points out, you can look at what version of clojure cider is using in the message. It was different from what i got at the command line. So after verifying one version worked but not another, it was fairly obvious. When i run clj /clojure from the command line it tells me the version of clojure, but in this case it seems it was the version of tools deps that was different between the two. e.g /usr/local/bin/clojure starts a repl with "clojure 1.10.1" and the other version in /home/drewverlee/.linuxbrew/bin/clj says "clojure 1.10.1" so part of me assumed they were a symlink/alias.
So, you asked how I got on: I decided to try one of the pre-built images. The test/pull-request checks are working, but not the deploy. I get a TransferFailedException. I'm literally only hours old as a CircleCI user and I'm probably doing something basically wrong.
cool
@alexmiller Thanks for the add-lib3
branch -- very nice that it works from source again, albeit without S3 support! Just updated my .clojure file for that.