deps.edn? - Githubissues

gfredericks commented 6 years ago

At the very least we could move the dependencies to a deps.edn and use that leiningen plugin.

Would have to check that codox and the jar tasks still work.

daveyarwood commented 5 years ago

If the codox task no longer works, you might consider switching to cljdoc, where the docs update automatically each time you push to clojars.

gfredericks commented 5 years ago

Would a file with just {:deps {}} suffice? If so, I don't mind the theoretical duplication with the project.clj file.

daveyarwood commented 5 years ago

I'm not sure how useful that would be, since I don't think it would change the behavior of the clj tool at all. If you had dependencies, you could certainly have a deps.edn that just has the :deps and nothing else.

If you're interested in migrating from lein => tools.deps, maybe this minimal deps.edn from one of my projects could be helpful as a reference. It uses pack and deps-deploy to automate building a jar and deploying it to clojars.

Granted, it's been half a year and I've heard of other tools for packaging/deploying deps.edn projects, so it might be worth looking around and seeing what else is out there at this point. One thing I found strange with the setup I used is that I ended up needing to add a pom.xml to the repo, and I'm curious if there's another way that can auto-generate the pom.xml at jar-building time.

gfredericks commented 5 years ago

There's at least the advantage of allowing people to depend on particular git commits, isn't there?

daveyarwood commented 5 years ago

Oh! I hadn't thought about that. I think you're probably right.

gfredericks commented 5 years ago

Okay, I just added one.

I wouldn't mind a full deps.edn dev setup, if somebody wants to do it (and make sure I know how to use it, in particular make releases to clojars and do all the GPG stuff), but I don't think I'd want a pom.xml lying around.

gfredericks / seventy-one

deps.edn? #19