Clojurians Log v2

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]}

it has been suggested, yes

at some point I will think more about it :)

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.

FYI: the issue is https://clojure.atlassian.net/browse/TDEPS-116

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

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 http://ask.clojure.org?

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

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

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:

deps.edn
windows-extras/deps.edn
linux-extras/deps.edn

{:deps {lib/window-dll {...}}}

:deps {app/core {:git ...}
       app/core+windows-extras {:git ... :git/root "windows-extras"}}

oh, forgot about :deps/root

@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

yes, the first part I learned https://clojurians.slack.com/archives/C6QH853H8/p1615891133005300 and like it a lot

but might be useful to extend it?

well I’d find it useful anyway 😼

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

yeah

: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`))

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

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

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

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.

Clojure CLI https://clojure.org/releases/tools#v1.10.3.814 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 https://github.com/clojure/tools.deps.alpha/blob/master/CHANGELOG.md 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.

Awesome!

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 https://clojure.atlassian.net/browse/TDEPS-99.

No, not currently

Ok. Thanks.

if you want to vote for this, please do so here: https://ask.clojure.org/index.php/7865/allow-specify-maven-settings-provide-credentials-directly