Fork me on GitHub
#tools-deps
<
2018-09-11
>
john00:09:19

I could have sworn I've seen the #<some-object> notation before

gfredericks00:09:04

$ clojure -Srepro -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.2.1"}}}' -e '(Object.)'
#<Object [email protected]>

seancorfield00:09:08

Changed in 1.7

Clojure 1.2.1
#<Object [email protected]>
Clojure 1.3.0
#<Object [email protected]>
Clojure 1.4.0
#<Object [email protected]>
Clojure 1.5.1
#<Object [email protected]>
Clojure 1.6.0
#<Object [email protected]>
Clojure 1.7.0
#object[java.lang.Object 0x2cdd0d4b "[email protected]"]
Clojure 1.8.0
#object[java.lang.Object 0x702b8b12 "[email protected]"]
Clojure 1.9.0
#object[java.lang.Object 0x13df2a8c "[email protected]"]

seancorfield00:09:22

(the new CLI stuff makes this so easy to test!)

gfredericks00:09:11

for clojure in 1.2.1 1.3.0 1.4.0 ...

richiardiandrea03:09:35

We have a monorepo with this exact setup: https://clojure.org/guides/deps_and_cli#_using_local_libraries and sometimes we get the dreaded Manifest type not detected error...it is a local dep with a deps.edn and I wonder how I can debug what is going wrong...

alexmiller03:09:05

probably related to relative paths if I had to guess

alexmiller03:09:17

is it a transitive local dep?

alexmiller03:09:53

there is a known issue that transitive local deps resolve paths in terms of your current directory, not in terms of the dep, which can lead to issues with finding the correct “dep root” (where the deps.edn would be expected)

richiardiandrea03:09:52

@alexmiller yes it is a transitive dep that of one of the sub projects and one colleague has noticed that if he specifies it top level the problem goes away.

richiardiandrea03:09:25

Thanks then good to know the problem is known I will check Jira

richiardiandrea03:09:09

@cfleming thanks this is the reason of the Cursive message ^

alexmiller03:09:42

that’s the placeholder for it, there might be another one that’s same thing

👍 1
cfleming11:09:36

@richiardiandrea Thanks for letting me know.

dominicm17:09:29

@alexmiller someone in #leiningen just discovered that openjfx uses <type>pom</type> which wouldn't be supported by deps.edn

dominicm17:09:36

just as a data point

alexmiller17:09:38

tools.deps is hardcoded to look only for jar extension

alexmiller17:09:56

the original example in TDEPS-12 is all jars

dominicm17:09:29

Yep. This was something @malcolmsparks pointed out a little later. Pom is something that is logically consistent with classpath building. I don't know how type interacts with classifier, I suspect it's multiplicative.

malcolmsparks17:09:20

Not quite. Each classifier/type combination is specified in a separate dependency element in the POM.

malcolmsparks17:09:25

@alexmiller thanks for comment in TDEPS-12, I've been able to build a local version of tools.deps and patch it into my /usr/bin/clojure script, no problem. Still testing.

dominicm17:09:59

It might be that a classifier key is wrong, and it should be named otherwise, and be maps with classifier and type in.

alexmiller17:09:03

usually I just add the source directory of tools.deps.alpha to the front of the lib path in my clojure script :)

alexmiller17:09:45

poms are used for determining transitive deps but are not themselves artifacts that get put on the classpath (these are independent parts of the tools.deps extension spi)

alexmiller17:09:00

all classifiers in a group/artifact/version share the same pom

alexmiller17:09:15

which is in some ways deeply weird

alexmiller17:09:43

and really reinforces that GAV should primarily be about “one” artifact

alexmiller17:09:36

I think you could argue pretty readily that the case in TDEPS-12 for example should be different artifactIds, not classifiers, but I don’t run the world :)

dominicm18:09:32

I was thinking the same. But I did realize that having structure provides the opportunity for tooling to inspect it. Eg automatically fetching src & javadoc classifiers. In the TDEPS-12 case, tooling has less of a place, but could feasibly be done by a maven plugin

alexmiller18:09:29

source and javadoc are secondary info (just like Clojure meta) and make total sense to me

alexmiller18:09:33

even things like aot as a secondary classifier make sense to me as a variant of the same artifact

alexmiller18:09:17

any case where you’re putting more than one artifact from the same GAV on your classpath at the same time seems … weird

dominicm18:09:11

I don't know GAV. Google isn't too revealing either, what is it?

alexmiller18:09:09

I’ve merged with the borg apparently

cfleming18:09:30

Group Artifact Version (standard Maven ID)

alexmiller18:09:40

groupId/artifactId/version

alexmiller18:09:55

nice slack, out of order message delivery

dominicm18:09:27

My guess was surprisingly accurate. The version part didn't quite fit for me.

dominicm18:09:37

Just so I'm clear, do you think javadoc should be a separate GAV with a pointer from the root? Or that context does make sense for a classifier?

alexmiller18:09:18

no, I think the existing usage of classifiers for javadoc and source make sense

alexmiller18:09:33

I think cases like the one in TDEPS-12 are weird

alexmiller18:09:50

all those classifiers should be separate artifacts

dominicm20:09:54

I wonder how hard it would be to have a tool which synchronized your Maven deps to add a profile with javadoc and source. I'd love that for stack traces. A bit of a shame that it would be duplicative to isolate to an alias with the current classifier data shape. Not terrible I suppose though.

dominicm20:09:35

I suppose you could use such a tool through -Sdeps too, but then cider would have to become aware of it... Unless it was a dependency of cider, then everyone would have it and be happy forever!

seancorfield20:09:33

Not everyone uses CIDER tho'...

seancorfield20:09:18

(heresy, I know!)

dominicm20:09:58

I think intellij is the only editor that doesn't. And atom.

dominicm21:09:50

Intellij probably already does this, so is less interesting. Atom would miss out, but could integrate directly with the library.

alexmiller22:09:36

intellij does this already

alexmiller22:09:02

that is, download and use source and javadoc for libs