No.

Can be a prefix sha, if you provide the tag that matches it though.

So no way to always get the "latest"?

You can do it programmatically but not declaratively.

The clj cli is built around the idea that you can download requirements and cache the generated class path and re-use it

I need an equivalent of ":local/root" but without forcing everyone to symlink stuff or have the folders named in a specific way.

Things like snapshot and latest break that caching model

> I need an equivalent of ":local/root" but without forcing everyone to symlink stuff or have the folders named in a specific way. I feel like there's some disconnect here. Why would :local/root require symlinks or specific folder naming? To refer to a path outside of the project? But it also wouldn't work as "get the latest" because the user would have to update that other path manually either way.

> the user would have to update that other path manually either way. If you fetch the latest of the :local/root project and then re-run the main project, it grabs the latest, right?

This is how you would do it programmatically -- if the program is started with the Clojure CLI, and you're using Clojure 1.12:

;; (require '[clojure.tools.gitlibs :as gitlibs])
  ;; (defn load-master [lib]
  ;;   (let [git (str "" lib ".git")]
  ;;    (add-libs {lib {:git/url git :sha (gitlibs/resolve git "master")}})))

It is complicated, I think there are some open bugs where changes to local/root deps don't invalidate the cache

(`add-libs` may need some adjusting -- that code was originally for the add-lib3 branch of t.d.a back in the day)

also people can have their own aliases, their own dev profile pointing to their :local/root for each library they are interested in having the latest

I don’t know of any open bugs on the local cache invalidation

People want things, but it doesn't always mean they have thought through the consequences of getting them

I was trying to build a golang project the other day, and it was a mess because they support a notion of "latest" and also have pervasive caching of dependencies

> If you fetch the latest of the :local/root project That's my point - getting the absolute latest there would require an explicit user action. Might be scripted, but still an action. Same exact thing with any other way to refer to the latest version of a dep - there must be a user action of some sort to guarantee that the dep is indeed the latest. Even Maven caches RELEASE and SNAPSHOT versions (or at least, it used to in scenarios where I was exposed to it, so I could be wrong).

I don't think the particular failure mode I ran into there would apply to the clj cli, but it has strongly reinforced that snapshots and latest are just bad

My actual problem is: the team has decided to move out dev-tools related code (or anything that's orthogonal to things running on prod) out of the main repo and into a separate repo. Ignoring the politics of that decision, what's the best technical way of achieving this? devtools code would want to require namespaces from the main project. And main project would also use namespaces from devtools project, but only confined into a certain alias, e.g., dev

> what's the best technical way of achieving this? To combine it all again into a monorepo. :D Seriously.

@U064X3EF3 my mistake, I had seen a ticket related to that in jira at some point, but it looks like it was closed years ago

To combine it all again into a monorepo. :D Seriously.but why? If we force an agreed folder structure and do it via :local/root it would work, right? Polylith works the same way. So my question is: Can I do it without that agreed folder structure?

maybe I'm not following, but what about everybody defines a :dev-tools alias on their ~/.clojure/deps.edn that adds the deps with :local/root pointing to wherever they cloned each tool? That doesn't require people to agree on any folder naming and structure

That's additional work for anyone who would want to work with the project, but I guess it's the best option for now. At least until 1.12 is out and can be done programmatically, as Sean suggested.

> If we force an agreed folder structure and do it via :local/root it would work, right? Polylith works the same way. Not familiar with Polylith at all so can't comment. But with a proper monorepo, depending on the latest version of every single component is just a single git pull away. No switching directories, no specific folder structure outside the project, no symlinks, no "magic", no secret sauce, nothing inventive. Just a boring, but working, solution. Helps with a plethora of other things like finding incompatibilities before you push, common scripts, tooling, tests, etc.

what we do in the projects I'm working on is to add a dev alias per developer with customization in the project deps.edn, like :

{:deps {lib/lib {:mvn/version "..."}}
 :aliases {:dev/juan    {:extra-deps {lib/lib {:local/root "..."}}}
           :dev/darrick {:extra-deps {lib/lib {:local/root "..."}}}}} 

Yes, this works. But for some reason if the namespaces in lib/lib would want to require main project namespaces, this fails. Even though that works for ~/.clojure/.deps.edn. That I guess can be solved by lib/lib project to have dependency to the main project, also using :local/root. But in that case, both projects need to know the location of each other. That's some guaranteed way to have confusions.

But with a proper monorepo@U2FRKM4TW I'm not in disagreement with you. Monorepos are fine and work the best in most cases. Unfortunately, this decision has been made and to backtrack, I need to at least demonstrate how painful it would be to maintain things this way. For now, I need to find a way to make it work as a dependency.

Is this in a company? At my job, we have a devops repo that defines the versions of various tools and it’s on devs to keep it up to date. Most problems are solved by saying “did you pull latest devops?”

> At least until 1.12 is out and can be done programmatically, as Sean suggested. We have 1.12 Alpha 5 in production. Nothing is stopping you using 1.12 today 🙂

> For now, I need to find a way to make it work as a dependency. It seems like this thread would "demonstrate how painful it would be to maintain things this way"... It seems to me that the team has just made a bad decision and they should reverse it. Having two repos that both depend on each other (according to what you said above) sounds like a bad idea in the first place -- why did they make that decision??

Well, one of us wanted to execute a local workflow in a specific way. Some of us found it somewhat complicated. Even though the code is restricted to a certain directory, we felt that it could become intertwined with the main source. But also, because all of us are extremely busy, we want the review process of devtools development and everything involved with it to be separate and develop at its own pace. In retrospect, I think I was just happy to prove that was possible with deps.edn, and I just said: "yeah..."