Clojurians Log v2

wouldn't it be good to have more deps.edn sources to load from ? (to recap now it's root/user/project/config(cli))

I am still thinking about the monorepo problem

it would be the missing piece to avoid having either to hijack the user level conf or do deps.edn generation, or pass something to the cli as string I think

related: https://clojure.org/reference/deps_and_cli#_deps_edn_sources

I suspect i am not the first one asking that question

I guess https://clojure.atlassian.net/jira/software/c/projects/TDEPS/issues/TDEPS-174 would be that (kinda)

basically an option (or env var) to specify a comma separated list of deps.edn files at project level could be it. But maybe there are better ideas out there

./cc @alexmiller

aka "the fourth file" https://clojurians.slack.com/archives/C6QH853H8/p1611959766114500

🙂 indeed

I would make it "N files" so that people don't ask for the "fifth file" right after it's patched 🙂

yeah. in clj-kondo I support something like :config-paths ["foo" ...] so it will merge in foo/clj-kondo.edn and hooks, which in turn can include :config-paths relative to itself. You can set up an entire chain of configs. Basically a classpath of configs.

yeah that's a good way to solve the issue for good

I’m not yet convinced that this is the answer. I also think it’s important to separate the problems of shared deps mgmt from shared tooling config

I do not think N configs is a good answer

And I think it’s pretty crummy to need to pass stuff explicitly

do you already have ideas for potential alternatives?

I mean, solutions to that problem

No

I haven’t really sat down to think about it yet

Is there an “official” way to run clj with a java that isn’t on the path?

JAVA_HOME="path to java home" clj …

actually it should be JAVA_CMD="path to java executable" clj …

no, the latter won't work

but JAVA_HOME will

but only if java executable is not present in PATH, isn’t it?

yes

but that was the precondition in the original question

right, sorry, misread the original question

@alexmiller (or anybody else for that matter) a follow up question on my maven resolution question. It seems to me after reading up on this that maven poms can define extra repositories under the repositories element and that, if specified, the maven behavior is to use those repositories to resolve the dependencies for that pom instead of the one used to resolve the pom. Two questions really: a) I failed to find a definitive answer. This seems to be the maven behavior, but it does not seem to be well documented. Is there even a spec for this or is the implementation of maven the spec? b) does deps alpha use this mechanic of changing the resolution repository?

Is there a repo with the clj command line tools in (the scripts rather than the clj lib)? I just started work at a new place, and broke the build by upgrading to the latest version. They had a hacked/patched version that worked with http proxies. I think they might have opened a ticket, but I'm not sure which repo it would be on.

As a side note, it's interesting how maven discussions about resolution strategy (such as this one: <https://issues.apache.org/jira/browse/MNG-3056>) do not distinguish between the resolution language aka poms and the structure and the implementation of maven itself. These days we have quite a number of different resolution engines (IDEs, gradle, tools, lein, sbt, ivy, etc) which need to use the resolution language and do not necessarily care about the implementation of maven. I.e. the above issue discussion only talk about command line switches etc when the issue really is that the resolution language has a feature that everybody needs to adhere to.

Maybe something like juxt/aero #include tag could help compose a deps file from multiple sources otherwise. But that's static (no merging), even tho another tag could do that.

But that feels a bit odd now that I wrote it down

https://github.com/clojure/brew-install

https://github.com/clojure/brew-install/tree/1.10.2/src/main/resources/clojure/install

ah ok, and the linux install is in there too

ah there's no where to add an issue 😞

I guess http://ask.clojure.org?

that would be the first place I could think of

thanks 🙂

there are lots of poorly considered impl magic in this area of maven (particularly around security)

clojure/tools.deps will use the repos from the top-level deps.edn, and only those

well, top level merge, which includes root/user/project deps.edn (central/clojars included in root)

note that the scripts there have various string replacements that happen before the final version so you can't just use those directly

https://github.com/clojure/homebrew-tools is a repository for brew of old versions, but you can find the urls for tar/gz for old versions in those if really needed

proxies are supported for mvn repos in the current version (but not for git deps), so maybe be more specific on what you need?

re security - I've more and more come to believe that allowing transitive deps to add (or worse, replace) repos to find things seems evil

Yes it was the git deps, I've just voted on https://ask.clojure.org/index.php/7850/cannot-resolve-git-deps-through-proxy?show=10145#c10145https://ask.clojure.org/index.php/7850/cannot-resolve-git-deps-through-proxy?show=10145#c10145

They'd patched it as described in one of the answers, so I've done the same for now.

Agreed, seems evil. Perhaps resolution should fail at that point with a message containing the new repo so the caller can either add it or not, but at least be informed

gotcha, def plan to fix that, but depends on larger direction with tools.gitlibs

Thanks for the reality check and info

(jgit vs shelling out to git)

Also, I'm generally somewhat surprised as to the level of disinterest in for example version conflicts and resolution logic given that everybody, their mother and the kitchen sink is built using these tools and run into these problems. Everybody is driving around in steam cars and are generally not interested enough to stop and wonder if there is a better way. I realize I'm preaching to the choir here, but still, surprising.

makes sense

it's really shocking that it mostly works at all :)