This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-12
Channels
- # adventofcode (2)
- # aleph (2)
- # announcements (5)
- # aws (5)
- # babashka (25)
- # beginners (167)
- # calva (8)
- # cider (1)
- # clj-kondo (3)
- # cljsrn (19)
- # clojure (87)
- # clojure-conj (7)
- # clojure-dev (19)
- # clojure-europe (1)
- # clojure-italy (14)
- # clojure-losangeles (1)
- # clojure-nl (4)
- # clojure-norway (3)
- # clojure-spec (18)
- # clojure-uk (29)
- # clojuredesign-podcast (3)
- # clojurescript (40)
- # clojurex (11)
- # core-async (13)
- # core-logic (2)
- # cursive (16)
- # data-science (4)
- # datascript (10)
- # datomic (53)
- # emacs (1)
- # events (15)
- # fulcro (71)
- # jobs (1)
- # jvm (2)
- # malli (4)
- # nrepl (2)
- # pathom (74)
- # re-frame (1)
- # reitit (19)
- # remote-jobs (1)
- # rewrite-clj (18)
- # ring (2)
- # shadow-cljs (132)
- # spacemacs (22)
- # tools-deps (65)
I'm going to do a talk about tools.deps / clj next week at the conj - any burning questions I should be sure to answer?
@dominicm if those are serious, I'm not sure what any of them mean
I'm just teasing :) I was hoping tools.ant would give it away. Unless there really is a tools.ant...
well, Lancet was kind of like tools.ant :)
It would be interesting to know if there's ideas you have that you'd like others to execute. (E.g. Expanding on Lancet, building X, the community would gladly step up and at the least explore the domain for you)
yeah, I'll cover some future idea stuff for sure
@seancorfield maybe, we'll see
In earnest, the big questions I've had are: - how do I do java - how do I do thing I do with lein (usually uberjar) - how do I load the tests of my dependencies (usually in the context of a monorepo) - why would I use this rather than lein
"do java" == "compile java"?
Sorry, yes. How do I fold java into my program, or use java libraries from source. Stuff like that.
don't? :)
Good slide, yep :) (Although the team I said that to then introduced lein and took away all my lovely deps.edn)
Not so much "do java" but "do compile" in the presence of gen-class
etc I think would be interesting to at least mention (`compile`, binding the output directory, making sure it exists).
you guys are too far on one end of the audience distribution :)
These are really clojure questions, but is interesting how lein did all this stuff that we didn't understand. Even though it's simple to do yourself.
but I will keep those in mind
https://github.com/seancorfield/cfml-interop/blob/master/deps.edn -- does compile
of a gen-class
namespace (caveat about the compile target dir needs to exist). I don't think compile/AOT is that far too one end of the spectrum really -- lots of people seem to assume you need AOT because "everything" out there assumes :aot main.core
and uberjar with a compiled -main
🙂 That's a big difference when you switch to CLI/`deps.edn` from the lein
world (or even the boot
world).
Intro to lein tends to be lein new app myapp
; lein run
; lein test
; lein uberjar
; java -jar path/to/the.jar
-- so I think the equivalent story with CLI/`deps.edn` needs to be out there "officially" with at least some explanation of the differences.
(the current docs expect you to create your need project completely manually, for example, right?)
where "build" == what?
@alexmiller edited. Sorry, meant "create".
create and deploy an artifact?
"build" by itself is not a very precise word in this context
(link if you are interested: https://clojure.atlassian.net/browse/TDEPS-116)
it'd be a lot better if that ticket talked about a problem, not a solution
well, not by my reading
...just not very clearly: I want to author more fine-grained libraries that may have optional code/dependencies which won't bloat classpath when unneeded. With maven it can be done using classifiers. With gitlibs, it's all or nothing
I have like 3 questions about every part of that statement
but I'd suggest pulling the "optional code/dependencies" string as a place to start
I don't have time to have a long conversation about this right now but something like that is a far better title/thing to describe in a ticket.
"Allow specifying aliases in coordinates that point to deps.edn projects" is a specific change that might solve a problem, but unlikely to be the only possible change to solve those problems
Maven classifiers by themselves are just another dimension to your artifact coordinate (and tdeps already supports classifiers). They only get at this kind of a problem in combination with the Maven property system that allows you to conditionalize a dependency coordinate.
may be it's not worth saying to this audience, but does the following seem off? my general impression was that clj / deps.edn tries to address some key issues (e.g. pomegranate-related, git deps, etc.) and wasn't out to replace lein, boot, etc. i thought a somewhat natural path would be for existing tooling to start using clj / deps.edn (or tools.deps, gitlibs, etc.) to take advantage of its capabilities. iiuc, there are also new efforts to build on or make use of tools.deps + related: https://github.com/juxt/pack.alpha, https://github.com/EwenG/badigeon, etc. i've used at least one lein plugin (https://github.com/reifyhealth/lein-git-down) which, iiuc, makes use of gitlibs with varying degrees of success -- and iiuc there are other plugins (see the bottom of lein-git-down's README for some) that have made attempts. may be that these or similar things haven't "made it into the core of lein" is where some pain comes from?
If your future work part drops any hints about the more recent version of codeq tht you mentioned a few weeks ago in chat, you might be inundated with dozens of requests for more info, unless it is provided during your talk 🙂
that has nothing to do with tools.deps so dont see why it would come up
@sogaiu I went down that path with boot-tools-deps
but ultimately it was too difficult to meld t.d.a. and Boot due to their different worldviews on paths and dependencies for anything but the very simplest use cases. I don't know how lein-tools-deps
fares in that regard.
I think if lein
/`boot` adopted t.d.a. wholesale as their way to handle paths and dependencies at their core, then that "natural path" could happen -- but that's a lot of rework and potentially breaking as well.
And it's turned out that the effort that might have gone into that has perhaps gone into building tools on top of t.d.a. that provide the Leiningen-like features as point solutions you can mix'n'match (which is, to some extent, Clojure's general mindset). Both Leiningen and Boot are "easy" rather than "simple" because they are both "batteries included" -- which have served the community well for a long time but the CLI and the t.d.a.-based tools we have now feel more "Clojure-y" to me.
I agree wholeheartedly with Sean, tools-deps are simple and that empowers me to quickly hack together tools I personally need, because I don't have to deal with semantics imposed by build tool
I think there is a lot of space for libraries to emerge that help with that process of developing projects
I made a couple of libraries with tools-deps, and the thing that wasn't there is aid to generate pom.xml, for example. clj -Spom
is not enough — it's a good starting point, but my build scripts usually have to update different fields in pom, and dependency list provided by tools-deps might end up in different place... I'd like to see a tool that just helps me generating pom from data, and then I will use tools-deps programmatic APIs to provide information I need
Yeah, having a minimal pom.xml
that satisfies the needs of clojars/cljdoc would be a big improvement over what -Spom
produces by default but that would be a fairly simple tool to write I guess. Also something to update the version/tag in the POM file.
(shouldn't be core t.d.a./CLI functionality -- the community can easily build this... I just haven't quite felt enough pain yet to do write it myself 🙂 )
it seems metav just added POM generation with versioning just yesterday 🙂 https://github.com/jgrodziski/metav/commit/e0bfe47f3af0659ac2a0bc624db82f90e2e0a6fe
I could probably even build that into clj-new
to be honest so at least you start with a somewhat fleshed out pom.xml
file...?
> Pom.xml generation >I have added the option to generate a pom.xml file based on what is already available from clojure.tools.deps. It actually uses the sync-pom function from tools deps then goes to the generated/updated pom and adds the group-id, artefact-name and version based on what metav already establishes.
we are very happy users of metav so this is a welcome addition, maybe it would be nice to add this dependency to clj-new
? We are mainly using it’s sha
-based versioning but of course folks could use it for semver (who haven’t watched Spec-ulation 🙂 )
I haven't looked at it in many years, but Maven actually has support for storing pom data in arbitrary formats and there was even a clojure format way back when this was conceived of
maybe that's just taking on a lot more problems :)
sadly, no