added deps.edn to support tools-deps

[ptaoussanis]

@tstout Hi Todd, thanks for this!

I'm not familiar with tools-deps, is it expected that all libraries using Leiningen for dependency management would need to duplicate all their dependencies in a deps.edn file?

[tstout]

Yes, I suppose so. This could be automated: https://gist.github.com/swlkr/3f346c66410e5c60c59530c4413a248e.

I did not create this pull request to suggest you should change to tools-deps. It is merely a convenience for me and likely a few others. If you work in a locked-down environment, clojars is likely not accessible. tools-deps provides a convenient way to specify a dependency as a git repo rather than a maven artifact. This allows me to use the library easily in a restrictive environment without needing to use one of the lein plugins that can achieve something similar. The deps.edn file is needed for this to work. I created my own fork of timbre to include the deps.edn. This pull request is merely a suggestion to provide convenience to developers in a situation similar to mine and tools-deps is the primary tool being used.

[ptaoussanis]

Hi Todd, thanks a lot for the explanation - that's helpful.

Any idea if there's any Lein plugins available yet that'd automate this easily? A quick Google didn't turn anything up, but I'm not familiar with deps.edn tooling/terminology, so might have been searching for the wrong thing.

I'd be happy to include a deps.edn if it's something I could maintain automatically during deployment, and do across all my projects for consistency.

Cheers :-)

[tstout]

Here are few tools (I have never used any of them)

https://twitter.com/borkdude/status/1578050265567076353

https://github.com/EwenG/lein-to-deps

https://github.com/hagmonk/depify

[ptaoussanis]

Busy downloading packages needed to experiment with some of these tools. In the meantime, would like to confirm my understanding of some of this if possible-

If you work in a locked-down environment, clojars is likely not accessible. tools-deps provides a convenient way to specify a dependency as a git repo rather than a maven artifact.

So your environment blocks Maven but allows GitHub? Any idea if that's common?

Once you have something like {:deps {com.taoensso/encore {:mvn/version "3.12.1"}}, you then manually convert that to a GitHub resource identifier? Or some tool automates this for you?

Finally, main thing I'd like to understand: Let's say you've got a project, you're managing your own project dependencies with a deps.edn file, and you'd like to include Timbre in your project.

You're actually required in general to bring in all transitive dependencies on your own? Or the problem here is specifically that the transitive dependencies can't be brought in automatically in your environment because Maven is blocked?

[tstout]

So your environment blocks Maven but allows GitHub? Any idea if that's common?

The restricted environment I am referring to does not exclude maven completely. Public maven repos are blocked. There are accessible private internal maven repos. One of these repos is a clone of the public maven central repo sans artifacts which do not pass security and licensing scans. Since most clojure libraries are published to clojars, rather than maven central, they are not available in maven artifact form in this environment. I suspect this type of restriction is common in large corporations. I have only one data point supporting this suspicion however.

Once you have something like {:deps {com.taoensso/encore {:mvn/version "3.12.1"}}, you then manually convert that to a GitHub resource identifier? Or some tool automates this for you?

Your line of questioning has made me realize that the deps.edn I included in the pull request would require that I already have a locally installed maven artifact for it to work with tools-deps. I happened to already have those deps installed in ~/.m2/repository. I realize now that the deps.edn I proposed in this PR is not useful. It could be useful if changed to have git refs instead of maven refs. However, this would only have utility for environments not able to access clojars.

Summary: For some restricted environments, consuming clojure libraries not published in maven central can be problematic.

[ptaoussanis]

For some restricted environments, consuming clojure libraries not published in maven central can be problematic.

Understood, thanks for clarifying. So to come to a conclusion then: is there anything that can be feasibly done with Timbre at the moment that would be helpful in these kinds of environments?

Publishing to central would be quite an undertaking since (from my understanding) all transitive dependencies would also need to be available there, and most Clojure dependencies are not.

Is it possible that this kind of issue would be easier solved on your side? If this is a common enough problem, and affects most Clojure libraries - perhaps it'd make sense to have a consumer-side tool/script that recursively converts dependencies to GitHub resource identifiers in a preferred format?

Should this issue be closed?

[tstout]

I think a consumer-side tool/script would be a better solution. I think this issue should be closed.

[tstout]

closing, as proposed addition is not particularly useful.