Clojurians Log v2

@mfikes yep, I always set -K

I'm starting to lean towards having Planck enable it by default, with it being disabled via --no-auto-cache or some such.

I wonder if it would make sense to md5sum the source files(with compiler version as well) and store into the cache .js/.json files somehow. Global cache directory that could work between projects.

just thinking out loud, but this would be maybe too much work and risky for too little gain

@hlolli I for one would love a global cache in say ~/.lumo/cache, not sure about the implications of cross project but I generally share a lot of deps between projects, e.g. andare:0.4.0

there another thread on the lumo gh project discussion storing the cache inside of deps shipped over npm

like antonio pointed out, if we start shipping caches, then we are always going to have a bad time across compiler versions. How is it again in clojure, are aot's included in the uberjars, I forgot if that's the default or optional.

@hlolli It is my impression if you put AoT Clojure artifacts in a JAR you can run into similar problems (mismatches for different Clojure versions). TBH I haven't dug too deep into it other than having been burned a few times and then essentially avoiding it.

Then there's always the possibility of just compileing a js module and ship that (one function library for example), but I'm not sure how much redundant code is being used when one requires compiled cljs project from clojurescript. The plus there of course is useability for js users.

@hlolli yea definitely some pro’s and cons between shipping the compiled js. I’m definitely interested in the possibility of distributing the cljs src via npm, if for no other reason than debugging and transparency

the caches are really nothing else but compiled js, minus the cljs boilerplate (it expects cljs.vector type and all datatypes to exist).

I still do love the idea of giving a js team some compiled js

yes, ofc 🙂 I think we should do more of it

I'd like to see benchmark on: 2 cljs dependencies as .jar (with cljs sources) in cljs project against the same 2 dependencies pre compiled to modules in cljs project.

with the way spec/test.check was mentioned in the Clojure 1.9 announcement, it sure does feel like it's part of cljs proper. Cognitect seems to indicate that everything should be done with specs going forward. I think they covered the whole clj codebase in specs too.

so, I'd love to see it packaged in lumo 😄

@johnjelinek FWIW, Alex and David gave some insight into the future of Spec's bundling itself here https://clojurians.slack.com/archives/C07UQ678E/p1512749467000280

I suppose with test.check bundling it with Lumo (or ClojureScript or Clojure) could lead to a situation where some new generator or desirable feature is added to test.check and you'd simply like to upgrade to the latest release of test.check in order to take advantage of it.

what's the current path to upgrade to the latest within lumo?

I'm starting to become a fan of using the new deps.edn stuff to make all of this dependency management trivial. You can just

lumo -c `clj -Spath`

I didn't know that was a thing!

are there docs for that?

@johnjelinek I'd be worried that if you bundled test.check with Lumo, then you wouldn't be able to use some other version without waiting for a new release of Lumo. (Unless Lumo somehow made that possible.)

@johnjelinek Getting Started: https://clojure.org/guides/getting_started Guide: https://clojure.org/guides/deps_and_cli Reference: https://clojure.org/reference/deps_and_cli

👍 as managing dependencies with lumo becomes easier, pulling in things like test.check at will seems preferable to me

An advantage of using deps.edn is that if you want test.check in Lumo just put this in deps.edn:

{:deps {org.clojure/test.check {:mvn/version "0.10.0-alpha2"}}}

lumo -Kc `clj -Spath`

{:deps {org.clojure/test.check {:local/root "/path/to/your/test-check/tree"}}}

In other words, I suppose I'm arguing that bundling things into Lumo might make it easier, but things can be simpler if instead you decomplect. 🙂

wait ... the stuff in deps.edn also have to have a deps.edn? kinda like how npm relies on project.json?

No, you can use :mvn/version to point to a Maven JAR and things work normally. It is only the :local/root way of doing it that requires the target path to have a deps.edn file sitting there for that project.

Or, perhaps I'm wrong. It seems to auto-detect if lein is there.

(See "Local project coordinate" on https://clojure.org/reference/deps_and_cli)

"Currently only :deps is supported"

cool -- does this take a dependency on the JVM to work?

or will it work with lumo by itself?

clj requires the JVM

@mfikes probably better to use clojure instead of clj - the latter is just

$ cat $(which clj)
#!/usr/bin/env bash

if type -p rlwrap >/dev/null 2>&1; then
  rlwrap -r -q '\"' -b "(){}[],^%3@\";:'" clojure "$@"
else
  echo "Please install rlwrap for command editing or use \"clojure\" instead."
fi

@mfikes also I don't think clojure (the cli tool) depends in any way on leiningen, unless I'm missing something

@pesterhazy Yes. Wow, clojure -Spath is even faster. (About 12 ms instead of 43 ms.) Right, the tool doesn't depend on lein at all. It appears that it might support either parsing project.clj or calling out to lein in the future, in the case where you specify a :local/root dependency to a path containing an auto-detected Leiningen-based project. I only say this based on the appearance of :lein in these two bullets • Default is to auto-detect the project type (such as :deps, :lein, :pom) • Currently only :deps is supported at https://clojure.org/reference/deps_and_cli

got it

parsing project.clj directly may prove unrealistic, as you need to take into account profiles etc... so you may end up reimplementing lein

still better than build.boot 🙂

Yeah, I agree.

lumo/planck + clojure seem like a match made in heaven

Ideally, Lumo and Planck could just "support" deps.edn directly (thus requiring no JVM), but it seems much more pragmatic to just delegate that functionality to the clojure tool and let it take care of everything for this particular use case.

I'd go even farther and claim that the existence of clojure will cover a lot of the ground that Planck and Lumo cover. In other words, it is fast to start up, is easy to launch, can realistically be used to run Clojure scripts, etc.

time clj -e "(+ 1 2)"

yes, please support deps.edn natively

The challenging aspect is pulling down deps. Even clojure doesn't do that by itself, and delegates to external libs.

The download itself can't be difficult, but dependency resolution probably is gnarly

Yeah, whatever is in here scares me https://github.com/clojure/tools.deps.alpha/blob/9883f49d34c08aeaf67461cc2aa4881f42b6fd1c/src/main/clojure/clojure/tools/deps/alpha/providers/maven.clj#L17-L21

and here https://github.com/clojure/tools.deps.alpha/blob/9883f49d34c08aeaf67461cc2aa4881f42b6fd1c/src/main/clojure/clojure/tools/deps/alpha/util/maven.clj#L17-L40

org.eclipse.aether.transport.wagon.WagonTransporterFactory haha

I think, since lumo is kinda wrapping node ... you could leverage npm to actually download the deps where possible

that way you're not writing a new system