Clojurians Log v2

Clojure v1.10.1.697 (stable) landed at scoop bucket.

That was fast!

nice!

I actually tested this one about 100x more on windows than I have previously so hoping I didn't miss something

(thank you AWS workspaces...)

Looks like I've got some work to do for deps.clj :)

yeah, feel free to ping me if questions. there are a lot of changes

I actually meant to ping you prior and I forgot :)

I think I'll just diff the bash script I based the port on against the newest and then just start porting those. I think it's just a few command line options and then bump tools jar, done

the command parsing changed a bit and the interface into the clojure bits has also drifted a bit (although I ended up putting a lot of stuff back for -R and -C - removing those had slimmed it down)

also, there is a new exec.jar that gets included in the classpath for -X

so that changes the install

Thanks for the heads up.

👀

yeah

it's not as bad as it looks :)

I thought something changed about -A, but this still works:

$ cat ~/.clojure/deps.edn | grep depot
           :depot {:extra-deps {olical/depot {:mvn/version "RELEASE"}}
                   :main-opts ["-m" "depot.outdated.main"]}

clj -A:depot

there aren't many now

-T, -O, -Sresolve-tags were all removed, so those are breaking changes

-R and -C both still do exactly what they did before (but warn)

nice!

-A is still the same but will warn if you supply :main-opts

I didn't see a warning with clj -A:depot though, or did you mean command line args?

no, I meant an alias that has :main-opts

ah, hmm. old clojure on the path somewhere I guess..

$ clojure -Sdescribe
{:version "1.10.1.561"

:s

borkdude@MBP2019 ~/Dropbox/dev/clojure/deps.clj (1.10.1.697*) $ brew uninstall clojure
Uninstalling /usr/local/Cellar/clojure/1.10.1.697... (10 files, 18.7MB)
borkdude@MBP2019 ~/Dropbox/dev/clojure/deps.clj (1.10.1.697*) $ which clojure
/usr/local/bin/clojure

-M does more than it used to (takes all args) so that could potentially surprise someone expecting to use it only for the :main-opts and not use the other parts of an alias

if you've installed an @ release of clojure, you might need to explicitly uninstall those

What is the "official" way to pull in deps from an alias that includes :main-opts but start a REPL instead of running the :main-opts? Is that still -R?

you can do it with -R, but I would suggest just not doing this at all

break it into two aliases

It's very common to see recommendations for :test as an alias to include both :extra-paths ["test"] and :extra-deps <some test tool> :main-opts ["-m" "<run the tool>"] and it used to be that you could just use -R to pull in the test dependencies but start a REPL. Doing that now tells you -R is deprecated and to use -A for a REPL -- but if you use -A you don't get a REPL, it runs any :main-opts -- so I think that's going to confuse people.

Hmm, I guess you needed -C there as well?

Yeah, that would need -C:test -R:test ... OK, I'll just crawl back into my hole ...

(I still think -R should have been expanded so it could be the REPL option but I know Rich doesn't agree so this will be the last time I mention it 🙂 )

"very common" == where?

Cognitect's test-runner -- which is where everyone else will copy it from: https://github.com/cognitect-labs/test-runner#usage

See also the :test alias here https://github.com/Olical/cljs-test-runner#usage

on my list of things to update :)

my impression of cljs-test-runner is that it's saying to use -A for main opts so that's not a case of above

you'll get the warning, it says to use -M, and that's what you want

so tl;dr how can you pull :test alias deps? that's a pretty common thing for me to do (e.g. before hopping on a train)

I guess it finds tests to run by searching the filesystem (which I think Cognitect's test-runner does too). But both of those conflict with the :test alias in the system deps.edn which is where folks would normally get their :extra-paths ["test"] from so I guess it's really a bigger problem...

-P can be used with all other exec options to download deps, make classpath, but not execute (-P = prepare)

Both of those runners should really use a different alias than :test I think.

why is that a conflict?

Well, the cljs-test-runner :test alias hides the system alias so that's probably a bad idea (since you can't start a REPL with your test folder on the path without doing something else).

I don't understand why this is a problem

And the same goes for the Cognitect test-runner really: although it does have :extra-paths to pull in your test code, again you can't start a REPL with your test folder on the path -- unless you duplicate that path into a separate alias.

The conflict is between running the tool using :test and starting a REPL using :test.

(as you said: the solution is to separate the runner from the classpath/deps needed to run a REPL with tests)

those seem like two things

and you should have two aliases

Yes, we agree on that. I'm just saying that the two most common test runners for the CLI both do the wrong thing in their usage instructions.

e.g. :clj/tests for running, :test for extra paths and extra deps?

well I can change one of those two things real easily :)

The separation has always been "best practice" but it has never mattered really until now.

personally, I'd rather have a :repl or :dev or something

I'd be pretty happy to just remove the built-in :test alias too

I think this also highlights the lack of composability of aliases -- because if you split stuff into multiple aliases you either have to duplicate stuff in deps.edn under multiple aliases or you have to specify multiple aliases on the command-line to combine those separate things.

I'm ok with both of those answers :)

but I wouldn't rule out some other way to combine things later

I've been doing -A:test:runner for ages by this point so I "don't care" -- and I got to that point simply because of these "issues" -- but some folks have been very vocal about wanting to just have a single alias that combines other aliases so... ¯\(ツ)/¯

an alias can also be an arbitrary piece of data now right? can that be used to avoid duplication?

not currently

"data" != "another alias that is resolved"

that is, the clj aliases do not do that work right now

but they possibly could so that is something I'm thinking about

:aliases {:test {:compose [:test-deps :run-tests]} :test-deps {...} :run-tests {...}}

that's a lot heavier weight than what I'm thinking about :)

:aliases {:test #{#alias :test-deps #alias :run-tests} ...} 

(I just noticed we're in #clj-on-windows and this probably should all be in #tools-deps 🙂 )

this is far from baked

hm, reader tags... doesn't that go against: other tools should know as little as possible?

"this is far from baked"

Nice. Glad to know it's under consideration at this point. But you'd want to combine aliases in a specific order, right? (and sets are unordered)

"this is far from baked"

my point is, there are options

Hahaha... be careful... someone will make an alexmiller bot that just responds with that for any question! :rolling_on_the_floor_laughing:

what's the use of having :run-tests standalone, since it will need the deps to run?

It would be the only alias that needs the test runner as a dependency.

Both "run a REPL with test code" and "run tests" need something that adds "test" to the path and any dependencies your tests themselves need (such as test.check, expectations...)

That's why I have :test (for the REPL stuff) and :runner (for the test runner dependency and :main-opts). But then I have to say -M:test:runner to run tests (which I'm OK with) but some people want to just say -M:run-tests have it combine the aliases under the hood, or at least have the :run-tests alias pull in the contents of the :test alias and then add the test runner stuff to it. Am I making sense @borkdude?

This conversation reminds me of this tweet https://twitter.com/pjstadig/status/1138540715867365376

yeah, it makes sense what you said

Yeah, it's all about where the composition is: inside the tool or on the surface. Leiningen composed "everything" inside, CLI makes you compose "everything" on the surface.

I can't tell whether Paul's tweet is praising CLI or criticizing it (text can be a horrible medium for intent).

some people wrap all these clojure invocations into little bash or Makefiles anyway

so maybe it's not all that important from an ergonomic standpoint

We have a build shell script for that. But mostly it's for running a sequence of CLI commands across a sequence of directories (because: monorepo).

(it does have some composition shortcuts as well)

Anyways, I should stop shaving this yak and go back to working on HoneySQL 2.0...

if only there was a snowflake maker

:-D

I'll have a stab at deps.clj this weekend. Thanks Alex for all the good work you do.

same to you all :)