Clojurians Log v2

I released clj 1.10.1.754 tonight, which has a bug fix for -Stree from yesterday and updates the windows scripts. If anyone wanted to give it a try I can promote it to stable. You should see new format for clj -Stree and same for clj -X:deps tree (see https://clojure.github.io/tools.deps.alpha/clojure.tools.cli.api-api.html#clojure.tools.cli.api/tree for more options)

edn format tree nodes described at https://clojure.github.io/tools.deps.alpha/clojure.tools.deps.alpha-api.html#clojure.tools.deps.alpha.tree/trace-%3Etree

I updated my two dev systems and tested on a few projects, looks good. Updated the work system and ran -Stree against a few of our subprojects, looks good. @alexmiller

is it possible to run multiple functions via clojure, using multiple -X options?

no

once you do -X, all args afterwards go to the function you're running

@onetom You could always do -e "(do (invoke-fn1) (invoke-fn2))" 🙂

(well, using requiring-resolve for each function)

A new version of the clojure tools is now available (https://clojure.org/releases/tools#v1.10.1.754) • New, more informative tree format for `clj -Stree` / `clj -X:deps tree` • Added https://clojure.github.io/tools.deps.alpha/clojure.tools.cli.api-api.html#clojure.tools.cli.api/tree for use with `clj -X:deps tree` • Use https://github.com/clojure/tools.deps.alpha/blob/master/CHANGELOG.md 0.9.857

winding it's way through the homebrew tubes

1st attempt via a Nix derivation:

: clj -X:deps tree
Downloading: org/clojure/tools.deps.alpha/0.8.677/tools.deps.alpha-0.8.677.pom from central
Downloading: org/clojure/tools.deps.alpha/0.8.677/tools.deps.alpha-0.8.677.jar from central
Unqualified function can't be resolved: tree

: which clj
/nix/store/g7cpwnmzfl9ikxnm7gbnq3qqgj0mynwk-clojure-1.10.1.754/bin/clj

@alexmiller I notice that mvn-pom takes an argument argmaps as a vector of aliases -- I understand why it's called that but it's... less than ideal 🙂 aliases seems like a more intuitive name if we're going to standardize on a way to provide a list of aliases to tooling?

(is the tree function possibly going to take an aliases (or argmaps) argument so we can see trees based on, say, test dependencies?)

clj -Stree seems to work though. it has nice X-es and dots in front of the dependency names

@onetom Sounds you have a :deps aliases that doesn't come from the system deps.edn file?

That version of t.d.a is old.

The new CLI uses 0.9.857

seanc@DESKTOP-30ICA76:~/oss$ clojure -A:deps -Stree
org.clojure/clojure 1.10.1
  . org.clojure/spec.alpha 0.2.176
  . org.clojure/core.specs.alpha 0.2.44
org.clojure/tools.deps.alpha 0.9.857

i know it's the old one, that's why im surprised and showed what happened.

Like I said, you have a :deps alias in your user deps.edn I suspect.

ah, indeed. i probably copied it from your ~/.clojure/deps.edn

https://github.com/seancorfield/dot-clojure/commit/431a9f0ed6d763260bfa2c9b568f405b5bd59453 July 28th I changed that 🙂

I saw in https://clojure.org/reference/deps_and_cli there is a :default-deps option for factoring out version info for common dependencies. What's the recommended way to provide that option from a central location? (Something like https://github.com/walmartlabs/shared-deps is for lein)

@onetom There are only three deps.edn files: the system (that you can't touch), your user file (in ~/.clojure), and your project file.

i see and can probably do clj -Sdeps $(cat ../default-deps.edn) ..., but can i do that at some more fundamental level?

:default-deps only works in an alias BTW, as does :override-deps

i thought about using CLJ_CONFIG to override the per-user default within project environments, but that would also prohibit developers to access their personal tools...

We used to do that. It "works" but it introduces all sorts of problems regarding tools. We stopped doing that.

so do you require your devs so define certain aliases in their ~/.clojure/deps.edn in order for the walmart projects to work or that's the thing you mean you stopped doing?

i for example moved the ion-dev deps into the project's own deps.edn because we were accidentally using an older version on one of the machines and it failed in mysterious ways...

i just don't want to keep copy-pasting a lot of "boilerplate" setup, while we are in a monorepo, where it could be just centralized.

Unfortunately, there's no "good" solution for monorepos at this point. Or, more generally, for providing "shared project deps". Feel free to upvote this issue https://ask.clojure.org/index.php/9849/teams-common-dependencies-tooling-across-multiple-projects

We used to use the CLJ_CONFIG "hack". Now we're using a different "hack" that involves generating deps.edn from template files. Neither are good.

good to hear that "it's not just me" 🙂 the problem is that i don't even know what would a great solution look like... otherwise i would hack together something

both this and previous are again https://clojure.atlassian.net/browse/TDEPS-175

you can do this for now with -Stree

thanks for sharing the problem statement!

I think a reasonable solution is to be able to specify one-or-more additional deps.edn files that should be processed in this order: system -> user -> <specified deps.edn files in order> -> project deps.edn -> command-line -Sdeps

or you can use -Strace and whatever to create a trace.edn and feed it to -X:deps tree with :file

but that touches a lot of parts of tools.deps.alpha

Yeah, I know what the workarounds are 🙂

I'm asking about a "better future" 🙂

well, this is the same conversation we've already had, not sure what more you're looking for

I was at least hoping for a comment on the name of the argument, given our past conversations.

I'm not sure how to convey "haven't worked on it yet" more than previously :)

Fair enough. I was fishing for an opinion or a direction, that's all.

I mean, I'm about to do this for depstar so calling it :argmaps because that's what mvn-install uses is one approach, but calling it :aliases seems a bit more intuitive.

(one big "downside" to the exec stuff is that the names of arguments become part of the API so this is more important than it used to be)

I'm trying to build a clojure project in circleci and it depends on the cognitect-labs test-runner. This all works fine locally but when circleci tries to build, I get an authentication error when it tries to download dependencies. I've seen other folks with this problem and the solution is usually to fix the entry in deps.edn to use the "https:" pointer to the test-runner rather than the "git@" pointer but my project already does that. https://app.circleci.com/pipelines/github/cddr/test-machine/6/workflows/05e75093-3a28-438c-97b0-7bd0f9bc5132/jobs/6 I'm using the "clojure -P -M:runner" trick to download dependencies and save the cache before actually trying to run the tests and it seems to be at this point where it fails. Would you expect that to work ok? The code for the project itself is here: https://github.com/cddr/test-machine

Another question this has prompted is, where does clojure download repos it clones when a :git/url style dependency is used? Would be cool to delete previously downloaded repo in my local setup in order to test this locally without pushing to circleci each time I change something.

You may have an insteadOf rule in your ci git config that is forcing ssh urls

Ah interesting. I'll try to verify that. Thanks for the hint

I have helped multiple people with the same problem

This swaps before clj even sees it

circleci@518e1f74cd0a:~$ cat .gitconfig
cat .gitconfig
[url "<ssh://git@github.com>"]
	insteadOf = <https://github.com>
[gc]
	auto = 0
circleci@518e1f74cd0a:~$ 

right enough

Not sure if this is some recent change in default config

Yeah I'm using one of their pre-built base images containing tools.deps. I'll report back with where it sets this ~/.gitconfig if I can find it 🙂

@cddr there is a discussion in #circleci on this very issue, with more details

@cddr yep, had exactly the same issue. "fixed" it by adding rm -f ~/.gitconfig to my circleci builds

Hi is there a way to use paths/deps from an alias but skip the main-opts for instance, for this test alias

:test {:extra-paths ["test"]
         :extra-deps {lambdaisland/kaocha           {:mvn/version "1.0.690"}
                      lambdaisland/kaocha-cloverage {:mvn/version "1.0.63"}
                      lambdaisland/kaocha-junit-xml {:mvn/version "0.0.76"}
                      ring/ring-mock                {:mvn/version "0.3.2"}
                      mockery                       {:mvn/version "0.1.4"}
                      http-kit.fake/http-kit.fake    {:mvn/version "0.2.1"}}
         :main-opts  ["-m" "kaocha.runner"]}

@kirill.salykin The general recommendation is to separate that sort of thing into multiple aliases.

i see, thanks

So you have a :test alias with the deps/paths you need to access/run your test code in the REPL and a :runner alias that is the Kaocha deps :main-opts (and any additional deps needed)

is there are reason for such change? -R -C seemed quite useful to me

@alexmiller ^

^

I suspect cider-jack-in should be adding its own :main-opts after the :test alias (so that it "wins" in the merge process)

(I always start my REPL manually and then connect to it from my editor)

Indeed, this is exactly what happens

jack-in command: /usr/local/bin/clojure -Sdeps '{:deps {nrepl {:mvn/version "0.8.3"} cider/cider-nrepl {:mvn/version "0.25.5"}}}' -A:dev:test -m nrepl.cmdline --middleware '["cider.nrepl/cider-middleware"]'

No, that's not what I meant.

oh

I literally meant :main-opts so that it is merged last and "wins"

me too, never use cider-jack-in, don't want my editor to bring down the dev process, ever

-A:test sets -m which seems conflicting with -m from the cider

ah, so we need to migrate anyway

clojure -Sdeps '{:deps ... :aliases {:cider/jack-in {:main-opts ["-m" ...]}}}' -M:dev:test:cider/jack-in --middleware ...

Since there is no way to specify :main-opts without an alias (at least, not right now).

probably I should reach to cider people to discss this

thanks for help!

that's a clever idea. offhand do you know if that works for the past several versions of t.d.a?

(don't research, just if you know off-the-cuff)

Which "that" are you asking about?

the main opts in the inline -Sdeps and last merged wins

That's always been the way :main-opts works in aliases.

awesome. thanks @seancorfield

(I assume you mean "Clojure CLI" not "t.d.a"?)

yes. i always blank on how to specifically refer to the command line stuff, not the language, not the library it is built on, etc

i'll go with Clojure CLI from now on

@dpsutton Mostly I nitpick on that because the versions of Clojure, the Clojure CLI, and the underlying t.d.a are all different.

> This is another case where I think `-R` should have been retained for “REPL” operations and expanded to include both resolve-args (old behavior) and classpath-args -- in the same way `-M` was expanded to include resolve-args and classpath-args -- in addition to just `:main-opts` (old behavior). And `-A` deprecated. That would have been an easier migration path for people. But that ship has sailed that would be ideal indeed

i appreciate it. i hope it didn't sound snarky. i always grasp for the right way to phrase it so thanks

@kirill.salykin you can use an alias like :middleware/cider-clj in practicalli/clojure-deps-edn and a .dir-locals.el to switch off the auto-injection of cider dependencies, however it seems very strange to run two separate tools from one Clojure command, espcially as Kaocha does not interact with the REPL as I understand it, its only looking as the file system. This just seems weird I am afraid...