Clojurians Log v2
tools-deps
So I figure this might be of some interest to people on this channel.
I’ve forked @slipset’s deps-deploy to support a number of new features and have created PRs for each of them:
1. Configuration via :exec-args and all that means (i.e. overriding parameters via the CLI) https://github.com/slipset/deps-deploy/pull/18
2. Support for private S3 buckets via s3-wagon https://github.com/slipset/deps-deploy/pull/19
3. A new feature to allow overriding the version tag in the pom.xml with whatever you supply as a :mvn/version in :exec-args or more commonly through a command line override. My hope is this should help generating new artifacts with new versions in CI. https://github.com/slipset/deps-deploy/pull/20
I figured I’d mention this in case anyone has any comments or feedback here.
It’s yet to be documented, and slipset is yet to agree to any of it, and there are some other things I’d like to add too like the ability to influence more of the parameters that are passed into pomegranate/aether (which would allow for example configuration of proxies etc in deps.edn), but I thought it might be worth mentioning.
I wonder if the override feature might be better placed in depstar?!
I think there's a lot of ambiguity in pom processing right now
yeah that’s precisely my point…
Personally I feel like deps-deploy and depstar should probably be integrated into the same project. And use each others :exec-args keys etc..
Though I guess that depends on whether there are any plans for the cli tools to ever support task composition. (I know it’s been raised here a few times). Here’s hoping tools.build lets you compose tasks intelligently 🤞
The project I’m working on wants to build and deploy multiple builds (essentially themed versions of the same thing), and to do that right now I need to fire up two JVMs for each build — and we might need 10 builds at some point… So that’ll be a lot of time wasted in CI starting/stopping JVMs. Not the end of the world; but might add a minute to the CI time; when it could be more like 10 seconds.
Silly question, why not write a short clj file which calls them with the right args?
Assuming a functional api
Just found this https://github.com/applied-science/deps-library
> Silly question, why not write a short clj file which calls them with the right args?
Well this is my point. I can definitely do that, and likely will. But I’m only solving it for myself in one project. If you build a jar you almost always want to deploy it.
depstar and deps-deploy would ideally be aligned and integrated around common keys etc.
It looks like deps-library is essentially what that might look like, though with a traditional cli interface not an :exec-fn one.
The iteration etc is fairly unique to my project; but the integration of deps-deploy and something like depstar is common enough that it can/should be combined in my mind. If we had that it would make the job of my iteration/script even smaller (but also I think be widely useful)
Well it turns out this is a bit of a problem to doing it as a clj script: https://github.com/seancorfield/depstar/blob/5b1f9f02b34d07f88b42cbf2c2109d04b829cd8b/src/hf/depstar/uberjar.clj#L525
Just to be clear, I’d be happy to move deps-deploy in (almost) any direction that might help solve problems.
That’s pretty much my thoughts on what should happen too… I feel we need some community consensus on what that direction might be though.
Anyway that’s me done for the day… but will check back later / tomorrow.
The other common override along with version is the scm tag (which is usually v${version}).
Hi all. I'm trying to use a library in my deps.edn that's on our corporate artifactory. This site uses ssl client certificates for authentication. In Scala/sbt (our normal code), we set java options such as -<http://Djavax.net|Djavax.net>.ssl.keyStore=... -<http://Djavax.net|Djavax.net>.ssl.keyStorePassword=... in the environment ($SBT_OPTS). But I can't seem to get this to work for clojure. I tried just directly passing these in like -<http://J-Djavax.net|J-Djavax.net>.ssl.keyStore=... but it doesn't seem to work. I get a handshake_failure. Does this sound familiar to anyone? I can build the library I want locally and install it directly in ~/.m2, but that's an awkward way to work.
the reason that doesn't work is because -J options apply to the application JVM that gets launched -- your program.
the dependencies themselves are fetched in a previous invocation that doesn't receive those -J options
will defer to @alexmiller on how to use custom TLS on the deps fetching
Thanks, yeah, that makes sense. I can continue working (installing locally) for now -- just trying to make the workflow a bit less convoluted.
What are the usecases for overriding it?
The tag points at the commit or git tag with the release pertains to. So you should override it when releasing so, e.g. Cljdoc will pick up the write commit to read docs from.
thanks makes sense
Totally going to move away from garamond to your thing.