Stand alone executable jar

[cnuernber]

Just opening this up for actual discussion.

Based mainly on this project and the work I did in the ugprade-1.9 branch, I created a stand alone jar to process deps.edn files and produce a dot-graph.

Given our recent discussion on the PR, I was hoping to open up a discussion on whether a plugin is actually a good idea.

I believe (but I don't know this) that a jar with a fixed dependency on leiningen core would be just as useful and global but would be more stable.

You can use the deps viewer from the command line with no further work required.

1. You don't have to add it to lein/profiles.clj, you don't need to add anything to any plugins.

2. The environment it runs in is not user-dependent, aside from the JVM and the user's installed version of clojure. This removes a set of issues.

   Example:

   clojure -Sdeps '{:deps {cnuernber/depsviz {:mvn/version "0.3"}}}' -m cnuernber.depsviz -i test/data/deps.edn

I think it is worth an honest discussion about potentially EOL-ing the plugin and moving to completely command line based system.

[danielcompton]

This is an interesting idea. We'd still need to be able to read project.clj files, but I assume we could do that with the Leiningen core dependency?

The benefits of plugins are that you can ensure everyone in your team is using the same version when it is on a project, and you can reuse the plugin in every one of your projects if it lives in your user profiles.clj file. The downsides are that because vizdeps is going past the public Leiningen API, we are going to get broken sometimes, and it will make it hard to support many versions of Leiningen at once. At first blush I wasn't so keen on it, but after writing out this response I think it's worth considering more. I'm not sure if I'd want to EOL the lein plugin entirely, as it is a much more accessible entry point for many people, but maybe we could suggest the standalone JAR as the recommended version?

the user's installed version of clojure.

You're referring here to the Clojure command line tools, not the version of Clojure in their project.clj/deps.edn right?

Would you imagine the installation method for users to be a one-liner shell script similar to your example? And then we would publish the JAR to Clojars and let clojure download it for us?

[cnuernber]

1. Yes, we can just depend on leiningen-core. We already depend on maven stuff so reading pom files in a structured way is reasonable.
2. I would imagine the invocation to be like the deps.edn visualizer.
3. Definitely stand alone jar.

Really what I am going for is to make the tool not clojure specific but I don't know how practical that really is. Something you could use for projects based on maven, gradle, leiningen, and of course deps.edn.

Boot is maybe not worth it because of the unique snowflake potential.

In the grander scheme, dependency management is something that is hard and no one really does it well. Helping the entire java ecosystem do it better is actually my thought. This tool is something that I know concretely helps.

Also, one way to get clojure used by a lot more people is to build a few damn useful things for the java ecosystem. I was actually trying to think of some way to grade projects in terms of how messed up or out of date their dependencies are and shaming at least some of the really big useful projects that are repeat offenders.

Just thoughts really. But simply shipping little batch scripts like what I demonstrate above opens up the tooling to a lot more possibilities.

[hlship]

I would imagine an adapter for project.clj, and one for deps.edn, that would produce an intermediate format; that would be consumed by a common layer that could do the focus/prune/format/output side of things.

[cnuernber]

I really appreciate that you are still into this problem as I believe it has gotten worse actually.

As you may know, I tried to support both deps.edn and leiningen almost exactly in that path; I create a graph from both and then the graph processing is unified:

https://github.com/cnuernber/depsviz/blob/master/src/cnuernber/depsviz.clj#L128

I am not happy with this because it isn't working perfectly for either deps.edn or leiningen. I have not nearly enough test cases for edge cases (nor even knowledge of them); this problem really does have to be solved by the community if we want it solved well. I had to hack some internals of tools.deps because it throws away a large amount of dependency information just out of hand and then I can never get a full graph of what happened.

I filed a JIRA about it but Alex isn't going to touch that minefield any time soon I don't think.

It is almost like, for tools.deps, there needs to be an independent piece that first produces lazily the complete graph and then code that filters that graph down into the actual classpath. I am fairly sure the current tools.deps implementation filters the graph while it is discovering it thus making it impossible to root cause certain types of issues without debugging tools.deps.