Fork me on GitHub
#tools-deps
<
2020-06-23
>
deactivateduser15:06:22

G’day! Does anyone happen to know of an equivalent of lein-licenses (https://github.com/technomancy/lein-licenses) for tools.deps? Either my google-fu is weak, or such a thing doesn’t exist yet.

seancorfield17:06:38

I'd never heard of such a thing, even for Leiningen before. Looking at the code, I don't think it would be too hard to write a deps.edn-based tool that did the same thing if someone felt sufficient need...

👍 6
deactivateduser20:06:42

Yeah that was my thought too, and it helps a lot with license compliance (which has been a big deal most of the places I’ve worked).

deactivateduser20:06:33

Is there a standard place in a deps.edn to put license information? Maven offers such a thing, though it’s not mandatory so not universally adopted (which is a shame).

seancorfield20:06:56

There is nowhere in deps.edn to put such a thing. The repo might have pom.xml and you'd look in there, or look for a LICENSE file of some sort in the project root perhaps.

seancorfield20:06:05

Be aware that clojure -Spom does not add <licenses> into the generated pom.xml -- I have it because I start my projects off with clj-new and the templates for pom.xml in app, lib, and template all have a default pom.xml file with an EPL 1.0 license listed in them.

👍 3
deactivateduser22:06:58

Right, and most of the tools that do this kind of thing “for real” rely on source repository analysis to determine licensing, rather than (potentially incorrect) declarations in build files like pom.xml. The challenge in the Java ecosystem is that for dependencies often all you can reliably obtain is a pom.xml (and associated JAR(s)). That’s all lein-licenses uses, for example.

deactivateduser22:06:14

This is (part of) the problem that the https://spdx.dev/ is trying to solve, and I’m a bit of an advocate for their efforts. They would get a huge boost if language ecosystems (such as Clojure’s) were to adopt SPDX for licensing information.

deactivateduser22:06:10

While they’re better than some wild west ecosystems (cough Javascript cough), the JVM-based ecosystems are still a bit too cavalier in their approach to stating and disseminating licensing information, imho…

Drew Verlee21:06:46

{} Is a valid deps.edn right?

seancorfield21:06:52

Exactly the same as not having one.

Drew Verlee21:06:53

What could cause two invocations of a the same clj command to result in different outcomes? i get a error building my claspath "dont know how to create an iseq from symbol" and everyone else gets the desired result.

Drew Verlee21:06:09

something in my local maven repo?

Drew Verlee21:06:25

clojure 1.10.1

Drew Verlee21:06:34

i blew away my m2 repo and got the same result.

Drew Verlee21:06:14

that command as a missing curly bracket

Drew Verlee21:06:45

nevermind, its fine

Drew Verlee21:06:09

my argument order was wrong

Drew Verlee21:06:28

i needed to pass -Srepro first then Sdeps

seancorfield21:06:48

-Sdeps takes an argument, which is the {:deps ...} EDN.

seancorfield21:06:27

So it's not so much that you need -Srepro first as that you need the EDN immediately following -Sdeps

colliderwriter23:06:37

I have a repo with multiple related projects in it which i'm moving to tools.deps. Is there a way to include an external edn file so i can keep my aliases and common paths DRY?