This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-31
Channels
- # announcements (3)
- # aws-lambda (1)
- # babashka (122)
- # beginners (241)
- # calva (28)
- # cider (7)
- # clara (7)
- # clj-kondo (43)
- # clojars (5)
- # clojure (326)
- # clojure-europe (60)
- # clojure-italy (2)
- # clojure-nl (4)
- # clojure-spec (21)
- # clojure-uk (4)
- # clojurescript (162)
- # cursive (30)
- # datomic (3)
- # editors (5)
- # emacs (4)
- # figwheel-main (1)
- # fulcro (24)
- # gratitude (3)
- # helix (7)
- # honeysql (20)
- # improve-getting-started (1)
- # introduce-yourself (11)
- # jobs (3)
- # joker (2)
- # kaocha (15)
- # lsp (21)
- # lumo (2)
- # meander (3)
- # off-topic (34)
- # re-frame (6)
- # reagent (1)
- # releases (4)
- # rum (2)
- # shadow-cljs (37)
- # spacemacs (16)
- # tools-deps (16)
- # vim (23)
- # xtdb (32)
(that's with HoneySQL's repo but I can repro this in any project where I try to select a different version of Clojure with -X)
There is some traffic on the issues for http://github.com/slipset/deps-deploy I’d be happy to work on it, but it seems a bit of waste if the tools stuff is going to handle deploys. So, while not asking for a timeline nor a roadmap, what would the probability be that tools gets a deploy feature within 2021?
It’s not something I’m working on or expect to work on soon, but is an area I’ve looked at and would like to have a more comprehensive deps based answer to
Cool. Just for the record. I’d be happy to retire deps-deploy the moment there is support in tools for it.
new CLI prerelease 1.10.3.967 is now available - undid the compilation of the exec stub, that's just too fragile
Confirmed that works with -X and different versions of Clojure. Thank you!
I'll probably release to stable tomorrow
@alexmiller care to elaborate why the exec stub compile was too fragile? is tool.deps still compiled?
well, it has to mix into anyone's classpath that's using -X or -T so any pre-compilation risks tying you into a Clojure version and I'd rather have as few constraints there as possible. plus, it's just one namespace, so I can't imagine it really matters much anyway
still compiling the tools.deps entry points - that's all internal to the cli so much safer
it's not really a huge win (most of the code is calling into stuff like maven which is all compiled Java anyways), but it helps a little
it's interesting to consider the compilation story for -X and -T calls. you can still use the techniques in https://clojure.org/guides/dev_startup_time but I have spent some time looking at automating it inside the CLI (since it knows the classpath, the entry point, etc - it has all the knowledge). there are some tricky corners though so it's a future area to consider.
yes. I think the -X stuff could probably be done in the CLI (in deps.clj this would probably be trivial) and transformed to a program which is then handed off to the JVM.
@U04V15CAJ We rely on the exec stuff from our build.clj at work because we have several things we were running with -X before that we now run in process so we build a command-line that we actually run with the exec stub so that it can do EDN parsing of arguments. @alexmiller has indicated that might get lifted out into a library of some sort so it can be reusable (since it's kinda hard to use the exec JAR as part of a classpath).
how would that be different than what it does now?