This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-15
Channels
- # announcements (7)
- # aws (30)
- # beginners (141)
- # boot-dev (3)
- # cider (48)
- # clara (35)
- # clojure (94)
- # clojure-europe (6)
- # clojure-italy (20)
- # clojure-nl (19)
- # clojure-norway (1)
- # clojure-portugal (6)
- # clojure-spec (7)
- # clojure-survey (3)
- # clojure-uk (93)
- # clojuredesign-podcast (22)
- # clojurescript (20)
- # core-async (54)
- # cursive (29)
- # datascript (1)
- # datomic (4)
- # emacs (2)
- # fulcro (10)
- # jobs (17)
- # juxt (3)
- # kaocha (20)
- # leiningen (20)
- # malli (22)
- # other-languages (7)
- # pedestal (4)
- # perun (2)
- # quil (2)
- # re-frame (7)
- # reagent (3)
- # reitit (31)
- # shadow-cljs (18)
- # spacemacs (11)
- # vim (32)
Hey @ikitommi just a heads up that https://github.com/teknql/pablo exists for when / if you go to break malli into sperate libraries. It's still early days, but it's made to ease the burden of managing mono-repo-like libraries. Documentation is sparse at the moment, but I don't anticipate that you'll be slicing malli up too soon either
Oh, that looks great! How do you setup the artifact version when pushing to clojars?
Two options (again, sorry on the sparse docs)
either, you invoke it with an explicit :version
via the repl / CLI (cli coming soon)
or, it automatically looks at your git status and uses the tag
ie. if git is tagged at 1.3.0
and not dirty, it's 1.3.0
, if it's dirty then it's 1.3.0-SNAPSHOT
Might also make it so that if you're ahead of a tag (but not dirty) it does 1.3.0-SNAPSHOT
too
I ask myself that at least once a week 😉
I'm hoping to get pablo to ultimately compile as a native image
Also, I think the biggest thing that tools-deps gets right is that it forces your project into a edn map - lein allows real programming to happen inside the project.clj
file which can allow it to become quite the mess
But, I don't disagree that this is shoe-horning some lein-like functionality into tools deps
Yeah… my ideal setup right now would be actually to have Leiningen for the project management (because it already works) and tools.deps for dependency management. Too bad that lein-tools-deps doesn’t quite make it work.
The thing that kills me with tools-deps
is that they didn't make a project.clj
parser for when cloning via git... So if you attempt to depend on a git repo and they use lein and don't publish the xml file in the repo, you're SOL
It feels very unpragmatic
Well, you can’t correctly parse project.clj without running it. Although of course you could make it work in most cases.
Yeah, 1) you could naively parse it and cover 99%, and 2) sci now exists - so you could eval it at make it work in 99.9999% of cases
I think tools.deps is designed in such a way that you can add new dep types. But it’s not nice if it’s not there out of the box
Yeah I think you're right - I think the coordinates can all be expanded on via multi-method. But then I'm not quite sure how you get it to load those multimethods before trying to resolve the local deps.edn
file