Fork me on GitHub
#tools-deps
<
2018-04-14
>
seancorfield00:04:37

OK, something we've all wanted ever since Leiningen did the .core thing... clj-new SHA "f6fcc24bfa5d77167ff826990cd2c9c65eed4fed" prohibits single-segment or unqualified project names!

seancorfield00:04:12

clj -A:new app foo/bar or clj -A:new app foo.bar

seancorfield00:04:20

And, with that, I'm out for the day...

richiardiandrea00:04:50

That's great thanks a lot Sean!

seancorfield07:04:30

clj-new SHA "025f678af79c460e23f762aeb33dbb4af16f7ec7" now supports templates that are :git/url + :sha or :local/root (+ template name) -- https://github.com/seancorfield/clj-new/blob/master/README.md

seancorfield07:04:59

(rewriting the Boot generator stuff will probably be tomorrow/Sunday at this point)

john13:04:30

So what would be the pros and cons of moving some projects off private mavens completely and just moving to private git shas?

john13:04:12

or private git urls

john13:04:38

seems like you're duplicating your deps anyway, if you've got your snapshot in github

john13:04:42

While also just copying them to some yaven...

john13:04:39

in other words, unless I'm providing to some maven consumer that can't use clj, why use maven at all now?

john13:04:46

hmm, I wonder if a lot of clojure libs somehow depend on things living on maven...

richiardiandrea15:04:02

@john I think that clj deps are fairly independent from maven but I might be wrong, lumo is experimenting with npm packages for instance: https://andrearichiardi.com/blog/posts/lumo-npm-dependencies.html

dominicm15:04:41

@john None I've run into depend on things being from maven.

mfikes15:04:21

@john One small thing, at least for now is that ClojureScript's :aot-cache doesn't yet work on Git deps. But that could change https://dev.clojure.org/jira/browse/CLJS-2651

john15:04:21

@richiardiandrea @dominicm that's what I was thinking

john15:04:11

@mfikes hmm. Does that just mean that some cljs things won't be cached on first pull of the dep?

john15:04:24

But they still cache after that, right?

john15:04:42

or, if someone is using :aot-cache true then it'll break with git deps, currently?

dominicm15:04:23

It won't break. They just won't be candidates for caching.

mfikes15:04:04

@john It just means that Git deps behave like things did before :aot-cache existed: They do still cache locally on first build.

john15:04:37

so if you have a project where you're waiting to migrate to clj tool, because of the ongoing work on private maven repos, you might be able to just skip all that and depend on the git dep directly, right?

dominicm15:04:48

As long as you control the private project you're interested in, yes.

john15:04:53

Obviously I won't fully know until I try migrating a whole project over, but I'm just doing a sanity check first

dominicm15:04:57

True for internal projects, false for datomic 🙂

seancorfield21:04:38

This was something that I noticed as I worked on clj-new -- I forked it from boot-new so at first it still had a build.boot, which was the only place where a version number was stored, and was the only place that had anything to do with building artifacts and deploying them (to Clojars). And I was suddenly "Oh, wait! I don't need a Clojars badge on this project, or version numbers, or artifact coordinates... 👀 "

mfikes21:04:02

In ClojureScript there was a similar issue where it normally produces a version number as part of its build process, which caused a little grief with trying to use ClojureScript as a "buildless" git dep. But that has been resolved (parts of the system have been changed to cope without a version number).

seancorfield21:04:45

@mfikes Some Leiningen templates expect to be able to get at Leiningen's version number, which it assumes is in META-INF/maven/leiningen/leiningen/pom.properties -- which is why both boot-new and clj-new have that tree structure in src.

dominicm21:04:17

Would be interesting to know "your" version (as defined in the deps.edn) somehow. I guess it could be set by clj using system properties when starting a jvm... 🤔

mfikes21:04:58

In ClojureScript's case the solution we went with was to derive a fake version number from the hashes of all of the code in the source tree

dominicm21:04:17

That gives me 2 use cases for contextual information now: tools.namespace could use it for reloading, and to grab a common piece of build information: version.

dominicm21:04:01

I suppose it would need to be burned into the resulting UberJARs... but I can take of that 🙂

seancorfield21:04:21

And also the leiningen.release namespace. I tried to incorporate Leiningen 2.8.1 but it has a namespace with a def that slurps one of its own files when you load it(!), so I stuck with 2.7.1. Looks like it'll be "fixed" in 2.8.2.

mfikes21:04:48

My takeaway: Anything that needs to be "built" can be a hinderance for just using code directly as a dep.

mfikes21:04:05

(Including something as simple as a version number.)

hagmonk21:04:36

hey this is germane to what I'm working on

hagmonk21:04:06

I started patching depstar to support building thin jars and producing a folder of jar artifacts

hagmonk21:04:02

for the purposes of building a kafka connector (which requires a thin jar + deps in a dir), and for separating deps into a separate docker file layer for speedier builds

hagmonk21:04:13

question I'm facing at the moment: should things like version numbers or aliases that configure how to build the jar be in deps.edn, or kept exclusively as command line arguments?

hagmonk21:04:37

I don't see anyone shoving extra stuff into deps.edn, so I'm somewhat wary about storing build metadata in there

seancorfield22:04:17

There are pros and cons to both.

seancorfield22:04:04

If you have a project that expects to be built a particular way, it makes sense to have the build stuff in the project (so an alias for using depstar etc sounds reasonable).

seancorfield22:04:28

If you have a project that can be used "as-is" but could be built using any tooling available, don't put the build stuff in the project.

seancorfield22:04:32

That would be my guidance.

hagmonk22:04:20

thanks @seancorfield … right now I'm patching in clojure.tools.cli support to see how that feels in use

seancorfield22:04:40

I haven't switched that over to deps.edn yet. It's on my list.

seancorfield22:04:55

But I also want to switch it to .cljc for ease of maintenance.

seancorfield22:04:13

(and drop pre-1.7 support)

hagmonk22:04:42

Hah, I just realized depstar is @ghadi’s handiwork. That's why this code is so tight :)

hagmonk23:04:24

Ok, it's a bit unpolished, but if folks want to give the thin jar / dependency copying support I added, start here:

clojure -Sdeps '{:deps {depstar {:git/url "" :sha "9524dccdb37ee85b79d3a505447d1e5101f1a73d"}}}'  -m hf.depstar.core -h

hagmonk23:04:19

The TL;DR version is that -m hf.depstar.core jar works like lein jar, and -m hf.depstar.core deps works like lein-libdir