This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-14
Channels
- # beginners (53)
- # cider (10)
- # cljs-dev (23)
- # cljsrn (25)
- # clojure (68)
- # clojure-italy (4)
- # clojure-spec (25)
- # clojure-uk (7)
- # clojurebridge-ams (1)
- # clojurescript (10)
- # cursive (20)
- # datomic (21)
- # duct (4)
- # fulcro (1)
- # graphql (4)
- # hoplon (1)
- # java (7)
- # luminus (9)
- # off-topic (111)
- # om-next (2)
- # onyx (14)
- # re-frame (3)
- # reagent (9)
- # shadow-cljs (182)
- # test-check (32)
- # tools-deps (53)
- # uncomplicate (1)
- # vim (94)
- # yada (2)
OK, something we've all wanted ever since Leiningen did the .core
thing... clj-new
SHA "f6fcc24bfa5d77167ff826990cd2c9c65eed4fed"
prohibits single-segment or unqualified project names!
clj -A:new app foo/bar
or clj -A:new app foo.bar
And, with that, I'm out for the day...
That's great thanks a lot Sean!
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
(rewriting the Boot generator stuff will probably be tomorrow/Sunday at this point)
So what would be the pros and cons of moving some projects off private mavens completely and just moving to private git shas?
in other words, unless I'm providing to some maven consumer that can't use clj
, why use maven at all now?
@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
@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
@richiardiandrea @dominicm that's what I was thinking
@mfikes hmm. Does that just mean that some cljs things won't be cached on first pull of the dep?
@john It just means that Git deps behave like things did before :aot-cache
existed: They do still cache locally on first build.
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?
Obviously I won't fully know until I try migrating a whole project over, but I'm just doing a sanity check first
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... 👀 "
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).
@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
.
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... :thinking_face:
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
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.
I suppose it would need to be burned into the resulting UberJARs... but I can take of that 🙂
And also the leiningen.release
namespace. I tried to incorporate Leiningen 2.8.1 but it has a namespace with a def
that slurp
s 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.
I suppose it would need to be burned into the resulting UberJARs... but I can take of that 🙂
My takeaway: Anything that needs to be "built" can be a hinderance for just using code directly as a dep.
I started patching depstar to support building thin jars and producing a folder of jar artifacts
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
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?
I don't see anyone shoving extra stuff into deps.edn, so I'm somewhat wary about storing build metadata in there
There are pros and cons to both.
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).
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.
That would be my guidance.
thanks @seancorfield … right now I'm patching in clojure.tools.cli support to see how that feels in use
I haven't switched that over to deps.edn
yet. It's on my list.
But I also want to switch it to .cljc
for ease of maintenance.
(and drop pre-1.7 support)
Hah, I just realized depstar is @ghadi’s handiwork. That's why this code is so tight :)