@alexmiller @dominicm One example where type is important is where a project might depend on a .war file, containing some functionality. See https://codesjava.com/eclipse-maven-java-web-project for example. This is more likely to happen inside a large enterprise using J2EE, I doubt you'd find an example in 'public' repos but there are vast private ones out there. This still is about the classpath (Maven itself is primarily about classpaths, not file distribution). There are other types too: https://docs.oracle.com/cd/E19830-01/819-4712/ablgz/index.html. I don't think it's worth adding support for them in tools.alpha, but at the same time it would be good if any design around supporting classifiers can be extended (via growing) to support types as well.

https://clojurians.slack.com/archives/C6QH853H8/p1536336844000100

I think the 1-1 correspondence is actually quite a nice design. If you think of the artifact as the logical entity defined in the pom.xml file (with its version and dependencies), rather than an actual file in the Maven repo. 99% of cases there is a single file for the artifact, but sometimes there are also ancillary files (one per classifier), sometimes called secondary artifacts. While Maven does support depending on a primary artifact file of, say, version 1.0, and a secondary artifact of a different version, say, version 1.1, this is such a questionable practice it is unlikely to be worth supporting.

So in conclusion, I don't think there needs to be an extended lib name of {:groupId "group.id", :artifactId "artifactId", :classifier "classifier"}. The libname, with the :mvn/version, already uniquely addresses the logical artefact (defined in its pom). There should be a way of specifying the required classifiers, perhaps with a :mvn/classifiers entry.

One minor point is that Maven makes you a declare a dependency on each artifact file you want to download (and you just normally repeat the GAV coord with a different classifier). Therefore there might need a way of saying "this classifier please, but include the primary artefact too", and also 'this classifier please, but not the primary artefact". I think the latter case could be supported later if required via growing the design.

Having read https://github.com/technomancy/leiningen/issues/898 now I do understand the point about tools.deps being only concerned about the classpath and perhaps extraction of native libs needs to be out-of-scope.

Some libraries do the work themselves, http://usb4java.org/nativelibs.html

I can give you at least one more example that has nothing to do with native stuff

ClojureScript relies on a few contrib libs (like tools.reader). All of hose libs get built in both a source form (and deployed with no classifier) and in aot form (deployed with :aot classifier).

the idea of pushing this into the coord is interesting. The current extension SPI already supports extensions returning multiple artifacts per lib. I do wonder about whether this has impacts for walking the transitive deps? Something to look at.

I guess there’s still only one pom defining deps for a lib, even in the case where there are multiple classifiers

as I looked at it more, I like this solution and I have implemented it and committed the change for the next release - see TDEPS-12 for more

I was thinking again about self-contained clojure files I realized you could have a pretty clean impl at the cost of a mildly longer shebang line, if you publish a library (ideally with a very short name) that can read deps out of lines 2->N of a file, and execute everything after that using -Sdeps so the shebang would be roughly #! clojure -Sdeps '{:deps {lib7 {:mvn/version,"1"}}}' -m lib7.main I think the tricky part is that lib7 couldn't do a unix exec to replace the original jvm; so maybe the cleanest thing for it to do would be to have tools.deps as a dep, and call it internally, and make its own classloader with the resulting classpath... so A) are there any libs yet that accomplish anything comparable to this? B) is this crazy or impossible?

Startup time would be interesting

There's a library to make isolated class loaders from a deps edn.

Startup time would be boot-like

do you recall the library's name?

@gfredericks Shebangs do not get parsed into arguments.

And yes, someone has done something like that.

IIRC via file that can be read either as a shell script (that runs clj) or as Clojure code (where shell header gets ignored via e.g. ;). With #!/bin/sh shebang.

oh if you can't in any syntax pass two args to clojure then I guess that would kill that idea

#!/bin/sh
; exec clj .... $0
<clojure code follows>

Something like this.

having lots of deps crammed into one line is unfortunate

I bet some fancy bash could support multiple lines

Multiple lines of what?

deps

Why? I don't remember a requirement that shell script has to fit on a punched card 🙂

just annoying when viewing and editing

not a deal breaker

I'd generate this script instead of editing it manually.

generate it from what?

I guess I mean the thing I'm going for is casual self-contained shell scripts

not tied to anything else

so generating it kind of defeats the purpose

and yes, should be trivial:

#!/bin/sh
; CLJ="clj ..."
; CLJ="$CLJ ..."
; CLJ="$CLJ ..."
; exec $CLJ
<clojure code follows>

I wonder if you could take advantage of the deps map being a noop to have it outside the comments

so you get syntax highlighting and editor help

I get Syntax error: ";" unexpected for that sort of thing

this is the holy grail I think

#!/bin/sh
... magic bash
{:deps {...
        ...
        ...
        ...}}
... more magic bash, with exec
(ns wahoo ...)

This also uses a similar trick: https://github.com/borkdude/balcony/blob/master/balcony.clj

Does anyone have an example of how to use clj/tools-deps with AOT + uberjar?

":"; seems designed to avoid the error I mentioned above

yes, it was the shortest bash command I could find that was also valid clojure

I think @mfikes came up with it

would "" not work?

I guess not

what does : mean in bash?

it’s an alias for true

o_O

sure why not

so your AOT/uberjar question is about asking how to take a src dir and AOT compile it and put that in an uberjar?

yes, with tools.deps. With lein I can find docs on that, but with tools.deps not so much I guess

I thought I saw an uberjaring lib at some point

w.r.t. AOT, it might be true that by calling compile enough you will get class files written to the classes dir

but there might be lots of edge cases involved that I don't know about

e.g., if you have a top-level namespace that requires everything else, try clojure -e '(compile (quote that.ns))'

if [ ! : ];  then
    echo "True!"
else
    echo "False!"
fi
# prints "False!"

who wouldn't want to be able to write code like that!

however, this doesn’t seem to work:

if [ : && : ];  then
    echo "True!"
else
    echo "False!"
fi