Clojurians Log v2

Gotcha. I’m exited to hear tools.build could be a thing. I really enjoy working with tools.deps and the latest features look great :thumbsup::skin-tone-2:

👋 How do I pass a version to clj -Spom?

I need it for CI. or is there a more clever way to update the version in the pom.xml for clojars-deployment?

@timok generally you cannot. clj -Spom only updates your deps (and generates a basic outline).

There's garamond which can do that though

I’m using sed 🙂 https://github.com/xapix-io/axel-f/blob/master/.github/workflows/publish.yml#L45-L46

@timo you can use the maven versions plugin: mvn versions:set versions:set-scm-tag -DnewVersion="${version}"

ah thanks @dominicm @jlle. then I will keep the pom.xml in the repo.

if you want to publish from github, I wrote a github action: https://github.com/jlesquembre/clojars-publish-action

thanks @jlle but it's actually circleci but I will have a look :thumbsup:

sure, this is another option

thanks

Do you think that the new -T CLI option can be a better alternative to user.clj? I can imagine moving some repl helpers I have in my user.clj to a function and invoke that function explicitly with -T

no, that doesn't seem right

if you're starting a repl, you can use the clojure.main -i to do things like that

-T is for invoking external tools (although I think -T is actually going to go away anyways)

Was -T intended to be a specialized -R/`-C` combination?

I was looking on the CLI reference page for where you can use :deps in an alias and that seems to just be -T -- but I thought it was valid in some other use case...?

I think -T did not include the deps on the top level. Which I can see being useful. Kind of like a system wide alias, but for projects

It feels "simpler" to just allow :deps / :paths in any alias with the expectation that it overrides the top-level values... but I guess there's always the question of what happens if you specify two aliases and the first has :deps / :paths to override and then the second alias has :extra-deps / :extra-paths to add to those? Will people expect that to work on will :deps / :paths always "win"?

:deps/paths replacement was previously only available via -A, was pulled out as -T in past

we are reworking all of this stuff right now

Too many unanswered questions 🙂 Needs more Hammock Time!

already did it

paths replacement = classpath overrides?

no

:paths replaces the :paths in your project deps.edn

right

which is admittedly a very unusual use case

can be useful for a project within a project?

we're going to rename these to :replace-deps and :replace-paths

yeah, that's clearer

And if there are multiple of those, it'll be like :main-opts and only one gets picked?

it's not worth me going through all this by piece - it's all getting updated

so let me go work on that :)

an analogy with :classpath-overrides {foo/bar nil} could be :remove-deps and :remove-paths

FWIW, I'm liking the -X stuff (modulo always wanting :extra-deps to be respected by it) and I'm thinking it will simplify several pieces of tooling at work, since we can remove multiple namespaces containing just a -main function that exists solely to parse/route arguments to other functions that take a hash map 🙂

that's the idea (and usage stuff will be improved)

(our current problem is a couple of our servers are too old to be able to run the install script so I have to update them manually -- but that's not Clojure's problem 🙂 )

also working on ideas to make ad hoc -F variant a bit more useful for the case of one namespace with many entry point fns

have I talked about -F yet? I can't even remember now

no, go on ;)

-F is like -X only without needing an alias 🙂

yeah, invoke ad hoc function

why even have X then?

lets you package default args and not repeat the fn at cli

both useful in different contexts

Invoking via an alias is more flexible. Yeah, default args, simpler name, will be even more useful when it respects :extra-deps 🙂

you can stuff default args in the function itself though?

Sure, but you could have different aliases with different default args. That's a use case that we could leverage at work.

-A:foo -F foo/bar, respects extra deps of foo alias?

Currently, you'd need -R:foo -X:foo for a function alias -- repetitive! -- so if -X respects :extra-deps you could just do -X:foo

But -F is definitely useful for ad hoc command-line work.

instead of creating different aliases with different defaults, one could also just write multiple functions in one namespace. I don't directly see the benefit of one over the other, -A:foo -F foo/foo, -A:bar -F foo/bar.

this is coming

sure if you bake it into the code

putting it in deps.edn is default but configurable

I guess having it closer together is one benefit

Yeah, at this point I'm just sort of assuming it will do that 🙂

-F seems like -e? But with less (

-e is arbitrary expression, -F is "invoke a functional entry point that takes a map" so it's much more specific