Closed DerGuteMoritz closed 2 years ago
I think that's a nice addition!
Cool, glad you agree! I guess we have to decide on how exactly to go about this then. We could provide the cited generic build namespace from this repo which we'd then generate a git dependency on for the :build
alias. Also, I just realized that we could just also put the contents of build.edn
into deps.edn
under a namespaced key within the :build
alias and then read that from the build task itself. Adding it as :exec-args
would be cool but :deps/prep-lib
tasks are run via -T
which (AFAIUI) don't support it. Will give it a try anyway, though. Sound good?
Sounds good!
:+1: PR almost ready, only one thing to sort out: https://ask.clojure.org/index.php/12298/should-deps-prep-lib-honor-exec-args-in-the-build-alias
Figured that we don't have to wait for this to be fixed. Tested locally with Aleph and it appears to do the trick :+1:
Leiningen supports compiling Java sources out of the box (via
:java-source-paths
). Supporting this to some degree would be desirable because it unlocks using libraries relying on this to be used as git dependencies. This requires generating a:deps/prep-lib
task. In Aleph, we already have this. It also generates abuild.edn
file from the relevant Leiningen settings which is then consumed by a generic build namespace. Do you think including something like this inlein2deps
is worthwhile?Some background on the workflow in Aleph: The idea is to keep Leiningen around as the leading build tool (at least for now or maybe even indefinitely) and generate a
deps.edn
whenever we changeproject.clj
which provides just enough to be able to use Aleph as a git dependency. We'd be happy to switch over tolein2deps
so that we can share the maintenance burden for this.