When using a git repo, can you make it depend on a particulars branch head instead of a specific sha?

Say I always want the latest commit

My idea would be to have a release branch, where each commit is a new stable release

@didibus Take a look in my dot-clojure file -- I give an example of how to resolve master HEAD to a SHA in there.

Basically, tools.gitlibs provides tag/branch resolution

Hum

I see, but that's basically the same as the user going to github to lookup the latest sha, just instead he can find it from inside a Clojure repl

Or asking him to always dynamically inject the dependency

You can hide it away behind a bit of code, but yes, it requires a lookup and a dependency load (my example is via add-lib).

I was hoping for something where I can just say, add this alias and done. Now the user always gets the latest release, so my CLI is pretty much auto-updating.

Like how mvn/version can be "RELEASE"

Yeah, it would be nice if :sha (or an equivalent) could specify a label to resolve first -- but that goes against repeatability.

And I believe even Maven's RELEASE is considered deprecated? Or at least somewhat bad practice...

tags are references, tools.deps only deals in values

using a changing version destroys the ability to cache and select versions

so it's intentionally not supported

Yes, and I understand it in the Java world. I think Release is deprecated or even removed in Maven 3.x. But in the Clojure world, tools.dels is also used as a minimal package manager for Clojure build tools and CLI apps. For that, repeatability isn't a concern, but auto-update is.

Your dot-file demonstrate that use case.

auto-update is not a use case tools.deps is trying to cover right now

Hum... Can't you still cache the sha of the head? Or you mean, the cache won't be as good since it will always need to check the repo for the latest commit sha?

sha's don't change meaning

The workaround I'm thinking is to wrap my CLI in another Clojure dependency that performs a dynamic add-lib and resolves latest. A kind of get-latest shim. But I kinda hate it

That one would never need updating (hopefully), and would always just bootstrap my latest

not saying this isn't a use case worth considering, just not one we are trying to cover right now

Got it

I can live without it and patiently wait. Just thought I'd see if there was already something of that sort.

I might be able to create an update command on the cli itself that edits the deps.edn file to its latest sha. That might be cleaner.

I am very pro for reproducible builds. And now that I'm thinking about it, I can't see good reasons for local deps.edn to not be version specific, even in their version of build tooling, test runner, etc. Since you want everything exactly the same to reproduce. But for the global deps.edn, which is more for installing Clojure utils on your machine, which as I see it, is like a package manager for Clojure apps, such a feature would be great.

Yeah

Although you’d be pretty unhappy if your tool auto updated and broke stuff

yeah I like the fact that I can pin the tools to a specific sha. makes troubleshooting much easier

I only use RELEASE for dev tools locally, although I made it the default in new projects created with clj-new -- on the assumption that when you start off, getting the latest versions is fine but you'd change it to a specific version as soon as you start to do any serious work.

(and I didn't want to get into the situation of lein where it often lags way behind Clojure's releases and you need a whole new lein release just to bump the Clojure version in new projects)

good point seancorfield

Hum... Ya. I'm wondering if a tools.deps tool could itself suffice. Like just have a -A:update-latest-deps

Which would resolve latest maven and git releases and update your tools.deps file.

So the user is in charge of when to update

It could even have a rollback feature

And what not, to make it more resilient in the case of breakage

Also, another thought that crossed my mind, and I'm just brainstorming at this point. I've noticed my default usage of Clojure cli is -A. Would it make sense then to default all unknown commands to be treated as an alias?

So clj new bla would be treated as clj -Anew bla

Like when it's not a valid path to a script

Most likely you would not want all Git deps updated, just certain ones.

Or to be honest I'd rather have to use say -s for running scripts, and aliases be the no option default

It's kind of important to have the -R/`-C`/`-M`/`-O` alias options tho' right? -A is convenient but kinda lazy.

Hum.. Ya I was wondering that. I guess I'm very much thinking here about the specific use case where tools.deps is used as an app launcher for Clojure and a build script launcher.

I won't speak for alexmiller / et. al. but it's my impression is that they are only interested in solving "resolving dependencies and constructing the classpath" right now

Ya, I'm kinda just wishy washy throwing some ideas which I haven't put much thought into. So none of this is criticism or even feature request, since I'm not even convinced any of this is a good idea yet.

It's just that, the more I think about "resolving deps and constructing the classpath" the more I realize that's basically all you need for being a package manager and app launcher for Clojure.

hi all, i'm trying to get a coworker setup with a clojure project and we are hitting this error

org.eclipse.jgit.api.errors.TransportException: [email protected]:foo/bar.git: fromBase64: invalid base64 data

The only real part missing is the idea of a "package". Its technically what an alias is. It's a preconstructed set of dependencies and main entry point which together consists of a working release of an app. But currently, aliases aren't easily shareable. Like you can't publish them, or update them easily. And launching them is a little ackward due to the use of -A.

@didibus The one thing I really "miss" with aliases is the abilty to compose them in deps.edn. Otherwise you either need to duplicate stuff under multiple aliases or the user has to specify multiple aliases on the command line.

(and I do generally use -A out of convenience rather than caring about whether I need -R or -M -- even tho' for things like test-runner, being able to use -R:test vs -R:test -M:test or -A:test would be "better practice" in a way)

Hum.. I feel maybe it's that aliases are currently used as packages, where really they were meant as ways to optionally add more or less dependencies to your running code, for development purposes mostly.

Maybe adding something like -P would make more sense for these use cases.

Where its clear you won't be changing the set of dependencies, but fully using the one defined by it

I don't see the "alias as package" similarity at all... puzzled

So, I might want to inject a test runner and also have my src on the path and run that. So I create an alias to inject the test runner. That's one use case.

But maybe I want to be able to run a command line editor implemented in Clojure. So I add an alias to it in my global deps.edn file and then to run it I do clojure -Acljedit bla.txt

This command installs the cljeditor app on my machine, and launches it. On the next run, the install step is skipped (because of caching).

In this case, I'm not interested in composing classpath dependencies. I'm not even coding. I want to install and run a Clojure app.

In that way, the alias is defining a package in the sense of Clojure app.

When tools.deps is used as a replacement for lein or as a build tool. Its kinds doing the same thing as well. In that you're adding all these convenient Clojure cli tools to your development environment. The difference is some of them also leverage tools.deps as the way to add your own code sources and resources which the build tool needs on the classpath as well.

Which is where composing classpath comes into play I guess.

It would be really cool to have an upgrade bisect where an attempt is made to update your dependencies and then run the tests. If they still pass you're good, otherwise you remove the upgraded dependency which caused the tests to fail and try again

Anyways, I'll think about all this some more and I'll stop with my thought dumping 🤤

one of the goals with introducing clj was to encourage more "small" build programs. I think that's been pretty successful. I think it's also useful to step back with where we are now and look at how people are using those, what use cases/problems we could support better, and what we could do to help. Eventually, we'll get around to that.

Running multiple programs seems to be the difficulty people keep stumbling over, from my observations at least.

like?

like a static set of things, or something where there is same input to all of them?

Figwheel, and then nrepl are the two I mostly see. And then combining them with rebel. It's not well suited to multiple mains because they need to background (except for rebel). But I also consider most of them individual choices rather than project ones.

That's why we wrote our build script: it takes a series of arguments and runs clojure for each one (plus some alias manipulation).

But the multi-main in one JVM is another use case that could be nice as a built in. It's no big deal to write your own -main to start up multiple things tho'...

We have a dev.repl/-main that starts up various combinations of tooling for that.

what if clojure.main took multiple -m's ?

@alexmiller it might work, I've done a little thinking, and I'm guessing that most tools would need to take a -d flag. The other side of this is "activation", the interface needs to be supportive to a user combining their own development programs with those of the project.

what's -d?

Demonize. Sorry.

by "multiple -m"'s, I assuming each would have their own main + args

-m foo 1 2 -m bar 3 4

so if foo or bar took -d, that would be fine

Me too. I just mean that eg nrepl would need a flag to indicate it should background itself.

ah, unless they launched in parallel in different threads :)

definitely things to work through, but seems non-crazy to me

It would definitely be interesting if multiple -m options launched the first N-1 in threads and the last one ran directly -- and then it waited on all those threads to complete.

no thanks

sounds like that can be done in userspace

if there were multiple mains, I'd expect the -main functions to return before moving on to the next one

there are so many choices in this neighborhood

I wouldn't leap to that conclusion

the conclusion i deleted?

Sorry to interrupt... is there a feature similar to lein clean in Clojure CLI?

clj -Sforce is probably the closest.

It ignores the cache, recalculates the classpath etc, and updates the cached values from that.

Hmm, ok. Thanks!

Although I guess you can get -d already with -e "(future ((requiring-resolve 'some.ns/-main)))" ... except for argument processing

of course then you have to decide who gets to call shutdown-agents

I guess the thread needs to have interruption configured for shutdown

Or basically daemonization

let's just reinvent pods! :)

Or not... 🙂

Boot is coming for clj I believe, so maybe that will happen.