Fork me on GitHub
Joshua Suskalo00:03:53

Has there been any consideration to adding a key to a dependency map which has :deps/manifest be of type :deps to permit including a vector of aliases to include? For example, I have a project intended to be used as a library which needs to include different natives jars depending on the OS, but without asking my dependents to include those native jars themselves I can't provide a good way to use only one set of them. I think it would be useful to be able to specify something like so:

{:git/url "some-git"
 :sha "abc123"
 :deps/manifest :deps
 :deps/aliases [:windows-natives]}
and have this bring in all the appropriate deps, based on the keys which modify paths or dependencies.

Alex Miller (Clojure team)00:03:42

it has been suggested, yes

Alex Miller (Clojure team)00:03:06

at some point I will think more about it :)

Joshua Suskalo00:03:39

Sounds good! I was mostly curious since this seems to be something that would require running a modified version of tools.deps, it couldn't really be done with additional tooling.


Btw I think there might be another solution to this problem — specifying path in the git coordinate to the folder in the repo of where the actual dependency is located

Alex Miller (Clojure team)12:03:51

You can do that now with :deps/root but I’m not sure how that does what you’re asking about


oh, forgot about :deps/root


That way there is no need to figure out what aliases are public and what aliases are internal and may change


I really like the ability to set the `:deps/manifest` to :deps to consume a standard clojure lib from git without needing a `deps.edn` upstream as long as the source files are in `src/` . Is is even possible set options this way? If not and I’d like to see it should I put it on

Alex Miller (Clojure team)12:03:30

I don’t understand what you’re looking for - what options?


My guess, mkvlr means: an option to set :deps/manifest :edn as the default if no pom.xml or deps.edn is found


Not sure how it scale, but you can control "profiles" with deps/root:

Where windows-extras/deps.edn
{:deps {lib/window-dll {...}}}
Then the consumer:
:deps {app/core {:git ...}
       app/core+windows-extras {:git ... :git/root "windows-extras"}}


@alexmiller @borkdude say setting another :paths or :deps in case the project requires it. I normally fork the project and make a fix and then I have another branch where I add a deps.edn because I only want to open a PR with the fix (and consume it locally) but not add the deps.edn upstream. A workaround for setting :deps is to add them to my root, but then it’s not clear what to remove later. Does that make sense?


@mkvlr you don't have to fork, you can add :deps/manifest :deps in your deps.edn for that lib


@borkdude and can I provide a different :paths and :deps for that lib in that case? Within the same map?


ah, so when the dep doesn't use the standard src and has other deps? hmm, right


but might be useful to extend it?


well I’d find it useful anyway 😼


:deps/manifest {:type :deps :paths ["src2"]}, something like that?


:deps/manifest {:paths ["src2"]} not sure if :type could even be omitted or if overloading :deps/manifest is right. It currently stands for a manifest type.


:deps/manifest currently indicates either :pom or :deps


yes, which is the type of project (from the docs: Default is to auto-detect the project type (currently either `:deps` or `:pom`))

Alex Miller (Clojure team)12:03:18

I don't think it makes sense for an external consumer of a project to determine the paths to use in the project, seems like the project creator should be the one defining that

Alex Miller (Clojure team)12:03:25

but it does make sense to me for a project creator to potentially provide standard ways to modify the classpath (presumably via aliases)


my use case is having this be a temporary measure for a lib to which I’m contributing a fix. Temporary until its merged upstream.


in some way :deps/manifest :deps is also an external consumer of a project defining an (empty) deps.edn

Alex Miller (Clojure team)13:03:54

there are already features in deps.edn for that - namely :classpath-overrides

Alex Miller (Clojure team)13:03:37

or :override-deps, depending what you're doing


yes, I can add the deps of the lib somewhere else (to the root or an alias or whatever) but the intention is less clear. At that point I’d rather fork the repo and add a deps.edn.

Alex Miller (Clojure team)16:03:07

Clojure CLI is now available! • git deps: switch from using jgit to shelling out to git (must be git >= 2.5) - big thanks to @ghadi for all the initial work on this! ◦ New env vars for control: ▪︎ GITLIBS_COMMAND - command to invoke when shelling out to git, default = git ▪︎ GITLIBS_DEBUG - set to true to print git commands and output to stderr, default = false • Made git fetch only when shas can’t be resolved to improve performance • Bump dep versions for tools.cli and aws api to latest (in particular, moves transitive jetty deps to latest, past a CVE) • Use 0.11.905 In general, this should resolve a large set of differences between using git deps through clj vs git at the command line, since they are now the same. Some additional benefits include a smaller deps footprint, and better performance.

🎉 39

Is there a way in to override the location of ~/.m2/settings.xml? I am trying to work around a limitation of our CI build system. This issue seems to be related