Clojurians Log v2

Does anyone know if https://clojure.atlassian.net/browse/TDEPS-163 is likely to be implemented any time soon?

probably not, but I did think more about it - the time when it's read by clj is in tools.deps.alpha, which is the process that builds the classpath. at that point you don't have any deps on the classpath (b/c that's what you're making). so it is more complicated than it initially appeared.

catch 22

ahh so the data-readers aren’t even available yet?

no

tools.deps could do what's in the ticket, and that would open that up for library use of tools.deps. but it won't help you via clj.

not sure I understand. Would it not be possible to read it with a :default reader in the first pass, and then re-read it later when you have that info?

@alexmiller With regards to env vars your reasoning was: the less tools have to know, the better it is. Doesn't that also go for reader tags?

when opening up reader tags, one could implement one which reads env vars (or wait, it was resolving your home dir), which brings the same trade-offs maybe

no? you would need to start a whole new jvm to do that

yeah

Yeah I guess it makes sense not to do it then, thanks for considering it though 🙇

what if reading tags is done with tagged-literal?

and then basis can be read with proper reader tags when there is a classpath..

What’s the problem reader tags are supposed to solve though?

giving a data representation to otherwise un(print|read)able things.

So my use case is essentially: I’m using integrant to define systems of components. Those systems are typically wired together in a base.edn file on the classpath. That file contains a map of integrant components. However it would be useful to override some parts (key/values) in the integrant system via the command line, and start the thing with clojure -X Or in prodution allow a user to specify their own profiles as :exec-args data in the deps.edn file directly. One of the things you may want to override though is an #ig/ref which basically states this component depends on this other component. My current example is a program that I want to communicate with two different deployments of the same system. One of which is authenticated via an auth0 provider, the other is identical but authenticated via a basic auth provider. I was hoping tagged reader support in the cli tooling would help with this; but it seems I’ll need to implement something to do this. It’s not too complicated; but it’s something I could use in a lot of projects, so I was hoping I could just leverage the cli tools rather than reimplement it each time; or require a library function to do it.

You can read the deps.edn yourself and have any data you like in the aliases

A good problem would be to avoid any error like that while computing the classpath from the deps.

That I would be happy to do

Hmm, agree, supplying non-data args via -X is complicated. My api functions in Reveal are supposed to only accept functions as arguments, but to make them available from clj-exec, I have to accept symbols as well and introduce polymorphism just to satisfy clj-exec: https://github.com/vlaaad/reveal/blob/master/src/vlaaad/reveal.clj#L11

If deps supported tagged literals, I wouldn't have to pollute my api

there is no straightforward way to do it. I wouldn't gate yourself on deps

I'm curious - what is the caching strategy used for looking up dependencies - I know that a particular dependency has been updated, it shows on clojars, but referencing it as 'RELEASE' in the deps.edn (my main deps.edn, i.e., $HOME/.clojure/deps.edn) I can see that it it's not being pulled down.

use real versions

@dharrigan it's a simple string hash on the user deps.edn, args and local deps.edn. Use -Sforce to update

Sure, I could do that - but I see for example in the popular seancorfield deps.edn, a lot of references to RELEASE as well. I mean it's not wrong to use RELEASE, it is supported. So surely, something must eventually attempt to find out if it is the latest release or not?

it is wrong

RELEASE is something that maven supports, but it's not encouraged by deps.edn, it just works because it works in maven. They will deprecate it.

RELEASE is a mutable reference

building caching on top of that is terrible, and clj relies on caching

Okay, fairy enough. I will use the version, not release 🙂

RELEASE is an easy vs. simple thing where people consistently choose what is easy

Indeed 🙂 We're all lazy 🙂

$deity knows I didn't become a programmer to be active 🙂

RELEASE is not officially supported by clj

use at your peril (it breaks the cache)

tbf, it (this library) was the only one in my deps.edn that has release for the coordinate

imo you should only ever use it in -Sdeps on the command line, not in a deps.edn file. I reserve the right to enforce that opinion at an arbitrary future time :)

it's on the list for clj-kondo warnings here: https://github.com/borkdude/clj-kondo/issues/945

Something else, does deps use the .m2/settings.xml at all?

yes, for some things (like server creds, mirrors, proxies)

right right, good. thanks 🙂

see https://clojure.org/reference/deps_and_cli#_maven

proxies for fetching maven deps, not for git deps?

yes, that is still a todo

there is a ticket for it, iirc

https://clojure.atlassian.net/browse/TDEPS-124

deps.clj has support for http / https proxy settings: https://github.com/borkdude/deps.clj - not sure if that's what you mean https://github.com/borkdude/deps.clj#proxy-environment-variables

I think it works in deps.clj because the proxy settings are also passed to the make-classpath invocation

that would make sense

https://github.com/borkdude/deps.clj/blob/02144768876f68445ed2c04cbf90c0b85b0e7d06/src/borkdude/deps.clj#L393

i can get the version from clojure by running clojure --help but it prints with lots of other text obviously. is there a way to get just the version?

we have a script that invokes -m and wondering whether its better to omit the -M and get a warning or include it and break usage for people who are on older versions

clj -Sdescribe will return edn content that includes a :version key

@dpsutton

$ clojure -Sdescribe | jet --query :version
"1.10.1.697"

note that the warnings are on stderr so you can redirect stderr to null too if you want to not see those

$ clojure -Sdescribe | clojure -M -e "(require '[clojure.edn :as edn]) (:version (edn/read *in*))"
"1.10.1.697"

$ clojure -Sdescribe | bb '(:version *input*)'
"1.10.1.697"

heh

but I have all these cat skins lying about...

k, one more:

$ clojure -Sdescribe | grep :version | cut -d' ' -f2
"1.10.1.697"

@dpsutton, I’ve moved to the new clojure command line syntax for rewrite-cljc. I have its scripts fail with an error message if clojure version < 1.10.1.697. My scripts are all in babashka so the check was easy.

thanks everyone

w00t. It will certainly help those coming fresh to Clojure and seeing your excellent deps.edn example.

Or the Practicalli example (nicer web site, more descriptive names, much better documentation). I'm considering linking to it from my dot-clojure repo and encouraging new folks to use the Practicalli stuff instead -- so I'm under less pressure to keep dot-clojure maintained and documented 🙂

@seancorfield I would be honoured to be linked from your repo. Thank you. The library versions used in the Practicalli aliases are updated at least once a month using the :project/outdated alias and version changes added to the changlog. Versions are updated sooner if I spot a new version or a library maintainer let's me know.

seancorfield/depstar {:mvn/version "1.1.126"} -- https://github.com/seancorfield/depstar/releases/tag/v1.1.126 -- just three small bug fixes; follow-up in #depstar

I was planning to make -X the preferred way of using depstar in that release but I realized that -X:uberjar ends up putting the Clojure CLI's version of tools.deps.alpha into the JAR file -- because depstar assumes the "current classpath" is what you want in the JAR (and it excludes itself, assuming it is the only dependency you don't want in the JAR). -X:jar works just fine (because it excludes JAR files). I'll need to modify depstar to use t.d.a directly to build a classpath from deps.edn files (per the discussion the other day) but that gets complicated if you need a "user" deps.edn file and you're using CLJ_CONFIG with a monorepo -- as we are at work -- so that will have to wait for "depstar 2". Given the discussions around that and t.d.a itself recently in this channel, I'll probably defer that work until t.d.a has better support for that (since CLJ_CONFIG is part of the clojure script, not t.d.a).

BTW, CLJ_CONFIG is documented officially (I thought it wasn't):

User - cross-project configuration (typically tools)

Locations used in this order:

If $CLJ_CONFIG is set, then use $CLJ_CONFIG (explicit override)

Is it possible to ignore a project’s deps.edn when invoking clojure cli? It would sometimes be useful when passing -Sdeps, e.g. in a tool that bumps a project’s version, or builds docs.

@hugod Yes, that's what :replace-deps is for.

See https://clojure.org/reference/deps_and_cli#_replace_project_environment_tool

thank you - I was looking for a command line switch

You can use it in -Sdeps but you'd need an alias I believe.