Clojurians Log v2
tools-build
should tools.build create a basis with more than what it is in deps.edn file ? I'm trying to publish a zip file in a maven repo (data for an app) and with the given deps.edn:
{:paths ["target/data"]
:deps {}
:aliases {:build {:deps {io.github.clojure/tools.build {:git/tag "v0.1.9" :git/sha "6736c83"}
slipset/deps-deploy {:mvn/version "0.1.5"}}
:ns-default build}}}(def basis (merge (b/create-basis {:project "deps.edn"})
{:deps nil
:libs nil
:mvn/repos nil})){:classpath
{"target/data" {:path-key :paths},
"/home/ieugen/.m2/repository/org/clojure/clojure/1.10.3/clojure-1.10.3.jar" {:lib-name org.clojure/clojure},
"/home/ieugen/.m2/repository/org/clojure/core.specs.alpha/0.2.56/core.specs.alpha-0.2.56.jar"
{:lib-name org.clojure/core.specs.alpha},
"/home/ieugen/.m2/repository/org/clojure/spec.alpha/0.2.194/spec.alpha-0.2.194.jar"
{:lib-name org.clojure/spec.alpha}},
:classpath-args {},
:mvn/repos {"central" {:url "}},
:test {:extra-paths ["test"]},
:build
{:deps
{io.github.clojure/tools.build #:git{:tag "v0.1.9", :sha "6736c83"}, slipset/deps-deploy #:mvn{:version "0.1.5"}},
:ns-default build}},
:resolve-args {},
:deps #:org.clojure{clojure #:mvn{:version "1.10.3"}}} :deps, :mvn/repos and :libs that I did not supply in my deps.edn file
you can choose what deps sources are included in the basis
by default, you'll get root, user, and project deps.edn
see doc at https://clojure.github.io/tools.build/clojure.tools.build.api.html#var-create-basis
you can pass :root nil, :user nil to remove those sources
thanks, that worked
would it be hard to expose all options for pom creation? I'm thinking of thins like: • ability to specify a different packaging besides jar • ability to specify classifier • ability to specify a different artifact extension(for zip packages or platform specific binaries ) - not sure if this relates to packaging above.
all classifiers use the same pom so that one is not a thing
packaging can be specified in the source pom
not sure what the last one is
in general, you can set anything in a source pom that is synced - the main things replaced are deps and repos (and some of the identifier stuff), everything else comes from the source pom
thanks, that worked as well. I managed to upload the artifacts I wanted
Does compile-clj expand macros? I have a macro that expands differently depending on the version of one of my deps and I am wondering if AOT compilation will bind my library jars to a particular version.
by definition, macroexpansion is part of compilation, yes
and yes, that will bind your library jars to a particular version, which is why we recommend that library jars should be distributed as source
Gotcha, thanks @alexmiller . I hear ya on distributing libs as source, and I would normally do that. Unfortunately, in this case my dep is scala-library (and other deps that form the Scala lang). My lib has some deftypes that implement Scala traits and require AOT compilation by either me (once before distributing the lib) or by each user individually. I'm debating how to handle this trade-off.
I didn't know about the binding to the Clojure compiler. That is a very compelling argument in favor of delaying compilation as much as possible.
it also binds your artifact to whatever version of the Clojure compiler happens to be used during compilation, which may differ from the version used by an app later down the line
in practice, it can be an issue to run on an older runtime (which is controlled by the app, not your lib) than you used to compile your lib, which is again, another good reason not to distributed a compiled lib artifact
is there a functionality to download dependencies to a specific folder or do I have to write my own? I could not find any while checking the deps-cli docs or deps projects list. The plan is to download the zip (s) I just uploaded and unpack them for building the docker image I need in the end. I find this to be very easy to manage via dependency management (version tracking and downloading) It worked very well in gradle for me.
You could specify the local maven repo to use (instead of ~/.m2/repository) I guess...?
that might work, but to which function should I specify ? I don't know which one is responsible for downloading the deps
resolve-deps seems to resolve them but I don't see the repo path option so my guess is that it's not downloading any of them
Usage: (lib-location lib coord deps-config)
this might also be useful
Ah, yeah, you could get the filepath after the download...
The option for which local maven cache to use is part of deps.edn so it would be part of the basis used for downloading the libs/files. Given what you're trying to do, just getting the "dependency"'s location on disk after the download is probably easier.
yes, I don't need to change the repo for this
do you know which function I can call to download the libs ?
I could not figure it out from the API docs of https://clojure.github.io/tools.deps.alpha/
resolve-deps does it automatically behind the scenes.
thanks, I'll play with that and see where it gets me
resolve-deps returns (or the basis includes) a lib map which includes the location of the libs
but setting a local-repo is a pretty quick path to this too:
clj -Sdeps '{:mvn/local-repo "my/repo"}' -P
thanks, Alex for the alternate solution. I got it working with
(tools/resolve-deps {:deps {'com.drevidence.docsearch/load-test-data {:mvn/version "0.1.11697"
:extension "zip"}}
:mvn/repos {"dre" {:url "surprinzingly, lib-location does not return the file name:
(tools/lib-location 'com.drevidence.docsearch/load-test-data
{:mvn/version "0.1.11697"
:extension "zip"}
{:deps {'com.drevidence.docsearch/load-test-data {:mvn/version "0.1.11697"
:extension "zip"}}
:mvn/repos {"dre" {:url "{:base "/home/ieugen/.m2/repository",
:path "com/drevidence/docsearch/load-test-data/0.1.11697",
:classifier nil,
:type :mvn}@eugen.stan Does the result of resolve-deps include the full file path you want? (no need to call lib-location)
yes it does - it's in a vector inside a map - grouped by group id
so I'll probably use that
getting back to lib-location - should it include the file name as well?
I seems to me like that can be computed as well and the information returned is not complete
I hadn't even noticed lib-location -- not sure whether it's really meant to be a supported part of the API or whether it just happens to be public right now? @alexmiller?
thanks for taking the time to help. going to seelp. see you tomorrow
lib-location is kind of a historical oddity at this point, I think there might be a Datomic thing still using it
In gradle you could define configurations and attach different sets of dependencies to each configuration.
And different parts of your programm could use the dependencies of one or another configuration.
This seems to be similar to how deps.edn has :extra-deps but in gradle you can choose not to inherit from a configuration - they are pretty independent.