Fork me on GitHub
#tools-deps
<
2019-11-12
>
alexmiller20:11:01

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?

dominicm20:11:04

Settle the debate on namespaces. Talk about java. Leak the plans for tools.ant

trollface 4
seancorfield20:11:45

@alexmiller Talk about add-lib 🙂

28
alexmiller20:11:48

@dominicm if those are serious, I'm not sure what any of them mean

😛 4
dominicm20:11:40

I'm just teasing :) I was hoping tools.ant would give it away. Unless there really is a tools.ant...

alexmiller20:11:12

well, Lancet was kind of like tools.ant :)

dominicm20:11:19

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)

alexmiller20:11:58

yeah, I'll cover some future idea stuff for sure

dominicm20:11:45

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

alexmiller20:11:29

"do java" == "compile java"?

dominicm20:11:19

Sorry, yes. How do I fold java into my program, or use java libraries from source. Stuff like that.

dominicm20:11:15

Good slide, yep :) (Although the team I said that to then introduced lein and took away all my lovely deps.edn)

seancorfield20:11:40

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).

👍 8
4
alexmiller20:11:28

you guys are too far on one end of the audience distribution :)

😄 4
dominicm20:11:28

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.

alexmiller20:11:20

but I will keep those in mind

dominicm20:11:08

I guess the recurring theme is "lein did X, deps.edn doesn't, where do I go?"

seancorfield20:11:59

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).

seancorfield20:11:28

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.

seancorfield20:11:09

(the current docs expect you to create your need project completely manually, for example, right?)

alexmiller20:11:16

where "build" == what?

seancorfield20:11:29

@alexmiller edited. Sorry, meant "create".

alexmiller20:11:36

create and deploy an artifact?

alexmiller20:11:24

"build" by itself is not a very precise word in this context

vlaaad20:11:50

how to build your own lein with tools-deps 🙂

vlaaad20:11:07

when TDEPS-116 will be solved 😄

alexmiller20:11:35

it'd be a lot better if that ticket talked about a problem, not a solution

alexmiller20:11:08

well, not by my reading

vlaaad20:11:10

...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

alexmiller20:11:52

I have like 3 questions about every part of that statement

vlaaad20:11:20

I'm ready to answer!

alexmiller20:11:42

but I'd suggest pulling the "optional code/dependencies" string as a place to start

vlaaad20:11:19

I don't have an account there unfortunately, can't edit the issue.

alexmiller20:11:20

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.

alexmiller20:11:05

"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

✔️ 4
alexmiller20:11:24

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.

sogaiu21:11:19

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?

andy.fingerhut21:11:29

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 🙂

alexmiller21:11:40

that has nothing to do with tools.deps so dont see why it would come up

seancorfield21:11:58

@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.

seancorfield21:11:00

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.

seancorfield21:11:05

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.

sogaiu21:11:11

thanks for the insights

vlaaad21:11:42

all "burning questions" for Alex to answer seem to be answered immetiately 🙂

vlaaad21:11:54

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

vlaaad21:11:40

I think there is a lot of space for libraries to emerge that help with that process of developing projects

vlaaad21:11:40

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

4
seancorfield21:11:23

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.

seancorfield21:11:15

(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 🙂 )

kszabo21:11:54

it seems metav just added POM generation with versioning just yesterday 🙂 https://github.com/jgrodziski/metav/commit/e0bfe47f3af0659ac2a0bc624db82f90e2e0a6fe

seancorfield22:11:25

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...?

kszabo22:11:38

> 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.

kszabo22:11:46

this looks like it fits the bill

kszabo22:11:12

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 🙂 )

alexmiller22:11:51

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

alexmiller22:11:25

maybe that's just taking on a lot more problems :)

dominicm22:11:15

Is there a dimension in which maven is not extensible?

😂 8