how do folks document the reason for a dep in their deps.edn? i was thinking we could just add a :doc "For feature x" key to the map alongside :mvn/version et al

;; need this lib because x

I have this: org.clojure/tools.reader {:mvn/version "1.0.0-beta4" :dictated-by :datomic}

i like that! what do you do for deps that are for specific feature code, rather than to support another dep?

I don't!

separate question: is there a dependency conflict diagnosis output in the tools.deps world, like the one lein has when you lein deps :tree?

You're creating 2 things you need to sync up. You won't remember when you need a new feature.

i agree, @dominicm -- the counter argument though is when upgrading dependencies, it's a lot of effort to dig around and understand how they are used. so i'm not planning reams of content. just enough to understand its importance and connection

On my list is the job to solve that through tooling :)

Kondo should make it fairly trivial to do at the namespace level

great point!

here's an example to do some namespace analysis stuff: https://github.com/borkdude/clj-kondo/tree/master/analysis#circular-dependencies

here's another one doing a namespace graph: https://github.com/borkdude/clj-kondo/tree/master/analysis#namespace-graph

The trick is figuring out which jars have which namespaces defined within, then mapping that to the dependency

Kondo supports jars though, so it isn't too difficult.

kondo also reports in which files the namepace are defined. it also lists the jar when you use the option {:output {:canonical-paths true}}

the jar string is a little bit weird though, I want to make it more compatible with http://java.net, so it might change a little

It should probably be the same as what io/resource would give me

yeah, that's what I want to make it

so expect a small breaking change there

Okay, won't write my code this weekend then.

it's only a small change, you can still use it to compare if it came from a different jar, to e.g. discover namespace conflicts

jar:foo:bar will become something like <jar://file>://foo#!/dude or something, I can't remember these details

I do that with sed atm. I think you really want to compare jars for conflicts at the file level.

maybe you can just specify what you need, so I can take that into account

if something isn't working for that purpose right now

I could make what's there work, don't worry. I'm just patient enough. http://Java.net compatibility would be good. What I'm planning on doing is linking the jar back to its dependency (eg bidi/bidi), then I know which namespaces use which dependency.

I just realized that {} is a enough deps.edn for some libraries

that was the idea :)

if you have no deps but Clojure and typical src dir, you should be good :)

yep, it's awesome. and even if a library (like medley before not too long ago) doesn't have one, you can declare a manifest type

@souenzzo or even no deps.edn at all 🙂

(! 1222)-> mkdir -p example/src/simple
(! 1223)-> echo '(ns simple.main) (defn -main [& args] (println "Hello, World!"))' > example/src/simple/main.clj
(! 1224)-> cd example/
(! 1225)-> ls
src
(! 1226)-> clojure -m simple.main
Hello, World!

Would it make sense for tools.deps to default manifest type to deps.edn if a project has no pom.xml / deps.edn? Why not?

if there's no manifest, why default the manifest type?

there's an implication/assumption I don't get

in the case of git deps with only a src folder, that saves you one file or some config 😛 probably a stupid reason

sounds stupid (you said it 🙂 )

I think defaulting to :deps would lead to confusing errors when someone tries to mistakenly depend on a Leiningen project that had other dependencies.

getting a magic ambient default seems like an undesired thing...

the reason I brought it up is that this option is often not known to people, maybe because the guide isn't very elaborate about it, although it does document it

I guess I don’t understand the problem enough to evaluate a solution

If you control the dir you can add a manifest easily

I was thinking the other way around: sometimes it's desirable to depend on a clojure project out of your control that only has a project.clj but no pom and no dependencies. what I did for medley is add a deps.edn to it: https://github.com/weavejester/medley/commits/master because that was more convenient to me than having to look up the exact option for manifest type again 😃

anyway, not that important I guess. have a good weekend y'all

It’s been a while since I tried but I though project.clj’s were read automatically

See ya @borkdude

I don't think project.clj files are read if you depend upon a git commit SHA of a Leiningen library that has no deps.edn, is it?

maybe tools.deps has a way to do that I do not realize, but it seems like that would be kind of magical ambient default, wouldn't it?

I could be way off here, but my guess was that a Leiningen library deployed as a JAR, e.g. to http://clojars.org, typically contains a pom.xml that tools.deps would use.

project.clj's are not read now

but maybe they will be in the future

I don't really want to change the defaults until that's sorted

I'm sure you know that project.clj files can contain arbitrary executable code...

so do sources files 😉

deps.edn files don't, though.

nor do pom.xml files

maybe more people should get into the habit of checking in the generated pom.xml files if they want their non deps.edn libs to be used

FYI, I am not here asking for new tools.deps features -- just checking whether I am missing something in what it does now.

I actually think it would be good to have project.clj support

I am undecided whether it should be naive support (data only) that relies on no leiningen stuff or good (perhaps add-on) support that does the actually right thing

or both

naive as in only read the :dependencies vector and be done with it?

would cover the first 80% probably

yeah. honestly I would love to know the actual number.

sandboxed execution of project.clj could also work for the remaining 20%

you mean eval?

yes. personally I would think it would be ok to only accept EDN-parsable project.cljs and ignore those with read-evals.

I am sure developers often download source of a Leiningen project and run Lein commands before looking whether project.clj does code execution, but at least they had to download the source for that to happen. Doing eval on the project.clj of transitive dependencies is another level of openness to exploits.

there's a fairly easy path to do the right thing using the lein code base iirc, but it does require depending on that code (which pulls in a bunch of stuff)

doing this the really really right way (like eval in clojail or something) is probably not something I personally am ever going to write :)

that's why I said "sandboxed", something like clojail or sci, so allow only a restricted set of functions. it sounds like a bit of a headache that may not be worth it for the 20% or less

think of the endless bug reports ...

same thoughts there

like I said, I'd be interested in knowing a better estimate of the %

if it's 99% then that's an easier decision

maybe it's more like 5% or 1%

Is the % number you are interested in mainly "is pure edn" vs. not? Or some finer distinctions would be interesting to know?

I guess you can retrieve a list of all clojars projects and then curl to their github repo and try to parse it with edn/read-string

I have swapped from read-eval to just templating an EDN-readable project.clj recently. the templating is done with clojure ironically 🙂

just whether a naive slurp edn/read find-:dependencies would work

if anyone wanted to get a believable estimate and write that code, I'm happy to consider it

and likely ignore any :profiles with their own :dependencies keys

not doing anything down that line

gotta run... later

just so we're clear, this is about using project.clj projects as git deps right?

that would probably exclude projects that have java sources in them

@borkdude I am happy to work on my other hobbies if this has set a fire under you. You would probably beat me to the answer, anyway 🙂 One perhaps additional interesting thing to check, if it isn't difficult, is whether the http://clojars.org pom.xml is "equivalent" to the top level :dependencies key.

@andy.fingerhut feel free to give this a go, I'm not doing this anytime soon, got lots of other stuff to do atm

As a sanity check on whether people often deploy pom.xml files that are a different dependencies list than the top level :dependencies key

Usually when I need a project.clj as git dep really bad, I just fork it and add the deps.edn myself

Not directly related to this problem, but there is a repo which collects stats from clojars as edn files: https://github.com/plexus/clojars-stats Could be of use for some kinds of analyses