@alexmiller I think a shadow-cljs user stumbled into a bug in tools.deps regarding :exclusions of libs. not sure if intentional.

{:deps
 {org.clojure/clojure {:mvn/version "1.10.0"}
  thheller/shadow-cljs {:mvn/version "2.8.37"}
  io.pedestal/pedestal.service {:mvn/version "0.5.5"}
  }}

shadow-cljs has a dependency on ring-core but excludes clj-time

[ring/ring-core "1.7.1"
    :exclusions
    ;; used by cookie middleware which we don't use
    [clj-time]]

pedestal.service also depends on ring-core but the exclusion from shadow-cljs is applied to its dep

so clj-time is missing

Do any of the tools-deps tools for generating an uberjar have support for something like lein’s :uberjar-merge-with?

Pack avoids conflicts altogether with a classloader.

The thing is, I need to merge edn files

e.g. data_readers.edn but in particular duct_hierarchy.edn

ok actually avoiding the conflicts and using a classloader would probably work… I guess I can just walk the resources and merge them myself. Which of the uberjar options will use a classloader? I’m guessing capsule?

hmmm… infact I probably don’t need to merge them myself… duct must be doing this already to work at the repl.

indeed it does: https://github.com/duct-framework/core/blob/c5fb68ac3539248942c50cdbba5a2ca63735ee3c/src/duct/core.clj#L42-L44 I’d literally just written those same three lines.

ok I can confirm pack.alpha capsule just works ™️ thanks

also capsule is awesome 😀

Capsule is very cool :)

Pack currently has a no conflict policy so that you don't have an option to shoot yourself in that respect.

:thumbsup: a good policy to have

what is the purpose of -e in pack.alpha? Why not just an alias with the extra-paths there? Or is it different somehow?

Is there any extra meaning in > Add directory to classpath for building

@rickmoynihan no extra meaning. That flag will continue to exist so that I can put directories generated with mktemp into the class path.

ahh makes sense thanks

The "for building" is probably a bias in my writing for my particular use case.

yeah — but that use case makes sense 🙂 the docs could possibly benefit from a clarification as to that purpose… but no biggie 🙂

it is essentially the same as :extra-paths but more suited for scripting/api usage in wider build processes

I'm terrible at writing documentation :)

@dominicm: incidentally it seems that pack.alpha doesn’t seem to honor :extra-paths in other aliases you supply during the pack phase. I’m guessing this is a bug? Though I could have my wiring wrong.

Hmmm, that would be a bug, yeah.

I thought I tested that though

ok I’ll open an issue for it — and also check it’s a real problem. Issue filed here: https://github.com/juxt/pack.alpha/issues/36

Reposting noob cli question from #beginners: Is there a way to create a “default profile” for the clj cli? Such that whenever I run clj, certain deps are always merged in?

like a ~/.deps.edn file or something?

you can include custom (private) aliases in ~/.clojure/deps.edn but as far as I know you always have to opt in to aliases

tools.deps prefers to be explicit

Yes, put a deps.edn file here $HOME/.clojure

Nah, you can just add normal deps

And they'll always be included

That's how Clojure itself gets loaded

Dumb question from a non-Java person: what is an “alias”? https://clojure.org/reference/deps_and_cli#_aliases doesn’t really explain that.

Also, -S seems to be missing from that list of possible aliases.

There are 3 deps.edn. The install one, the one in your home directory. And optionally, your project one. The :deps map gets merged from install to home to project. In case of conflicts, the later ones override the prior ones.

Aliases are like dynamic modifications

Normally, the classpath, that is, the path to all libraries available to your program is defined by the :deps map, and the :paths vector, and a few others.

But, maybe on occasions, you want to start a program or a repl with more or less libraries included

That's what aliases let you do

So you can define sets of dependencies and name them with an alias.

Now, from the command line, you can choose to include some of those additional sets by adding the alias for it

That’s a very helpful explanation @didibus, thanks. So including aliases merges the options contained in those aliases?

Ya

You said it’s possible exclude as well? How would that be accomplished, since it’s a merge?

Pretty much. Now the way things are "merged" can vary depending in the type of alias and config.

Well, you can't exactly exclude. So you'd be better off thinking of them more as inclusions

But for example, you can specify :override-deps which will override versions

Or :classpath-overrides which overrides the path to a lib

@d4hines As an example of what you can do with ~/.clojure/deps.edn, here's mine https://github.com/seancorfield/dot-clojure/blob/master/deps.edn

That has some usage notes as comments as well. Plus the README in that repo explains in more detail...

I'm not sure if you could classpath-override to a null dir

Or a dir which doesn't have the dependency

As a weird way to exclude

But I wouldn't recommend it

Better design it so aliases are additions or overrides, but not removals

Also, I'm not sure what you mean by -S, that's just a prefix for other cli options. It's not related to aliases.