Clojurians Log v2

you mean, as a word?

yeah

well it's a lot shorter :)

(Just got the image in my head of a clojure team meeting, but everyone is walking in dressed like a priest. Just instead of a bible its Marriam-webster)

seemed like a better semantic match and without most of the associations people will add to "config" etc

you're not wrong

i'll make a joke about this later i'm sure

so then from there - why basis over runtime-basis, does basis imply in context what it is for?

and what are some of the associations that exist for "config" that aren't applicable

what does "runtime" add over basis?

basis is a starting point, a context

it's really not about configuration (what I set) as much as the resulting resolved libraries and classpath, which forms the context for runtime execution

so the primary focus is the resolved libraries and classpath, not so much the jvm flags

even though they do get wrapped into the same thing

the focus is on the libraries and classpath

I think "runtime" might contextualize it as being "a basis for the launching of the jvm runtime"

but i guess the distinction only matters in the presence of basis-es for launching other kinds of processes

https://clojure.org/reference/deps_edn#basis says "The runtime basis is a representation of the dependency environment when the Clojure runtime starts. It includes information about the dependencies, classpath, and how the basis was created."

and runtime-basis assumes the jvm part already

so its an uncomfortable middle ground

as someone that has to type it all the time, I'm happy to shorten it to "basis" :)

What’s your basis for choosing basis? It’s succinct and only one word.

im choosing my own words for some of this stuff in one of my doodle projects, so im thinking about it a bit too hard

I haven't verified it but based on a casual scan of the code, I think you can pass additional exec args on the command-line when you prep and they'll be passed into the prep fn in each dependency -- so if you control the dependency, you can make the prep fn accept a specific path? Does that help?

You can have a prep step in your own project too, BTW, although I'm not sure whether it would run before or after any given dependency (and then specify prep :current true, with :force true if you wanted to re-run it).

I don’t think you are going to be able to do what you’re asking for

Or at least not in one step - prep is about preparing the on-disk project files (primarily for compiling new things on to the classpath). You should be able to prep and expand the jmod file into your project somewhere, but prepping doesn’t affect the actual command being run

So basically prep is a way to turn --class-path <original artifact> to --class-path <processed artifact> , you can't turn <original artifact> into --class-path <processed artifact A> -Dsystem.library.path <processed artifact B>

I was wrong about passing options/arguments into the prep fn, it seems. That's kind of both understandable from a security p.o.v. but also disappointing 🙂

yeah, that's just not sensible - prepping happens potentially across many libs so passing args to all of them wouldn't make sense

and correct, you are not affecting the system properties, just the effective classpath

(I am being a good boy and not making this about the --module-path)

native stuff is kind of a special case - Maven (and lein) do automatic oss/arch selection via classifier, extraction, and inclusion on library path. this is an area that clj hasn't tackled yet

oh, is jmod modules not native?

what do you mean by native?

native libs

jmod modules are a directory structure like

classes/
  <class files + module-info.class>
legal/
  <a bunch of legal docs>
lib/
  <native libs>
bin/
  <launchers>
...

so they are meant to be used "at link time" to build out a JDK, but you could also just explode them and put classes on the --module-path and lib on the -Dsystem.library.path

I haven't dug into these, certainly clj/deps are not handling them

i think they are interesting in part because 1. They actually handle native code unlike jars which require ad-hoc extract at runtime strategies 2. add sources and docs and its basically "the library" as an artifact 3. They are planning on (based on my read of the leyden mailing list) adding a static-libs section which would let you jlink everything to a single exe without the closed world assumption of native image

i guess also 4. - from my time digging at jaxb recently it is annoying that xjc, that schema compiler, comes in a bin folder in some random zip file. It is strange that for a certain kind of dependency (things you put on the class path) you can use automatic resolution, but for others we use different mechanics

it just itches my brain constantly

--os-arch "x86_x64" --os-name "Mac OS X"
  --os-version "10.10.5" greetingsmod

maven selectors have explicit tags for os and arch so I wouldn't say that's "random", but I don't have a good feel for how arbitrary it is

if you look at https://maven.apache.org/pom.html under Activation - this stuff is used to select a variant via classifier

you do the section based on those things, but which classifier to pick is undefined. You don't just say "I want library group/artifact/version" and it picks the one for your OS, you say "when os=.. and arch=.., I want group/artifact/version/classifier"

I guess that activation just ties you into profiles so there is indirection there

apologies for huge file, but this is how you get LWJGL in a pom if you want to support everything

hard to get away from huge files when you talk in pom ;)

so for this library the mac version has the classifier natives-macos and natives-macos-arm64

right

for a different library the classifiers will be different: you can't just interrogate the package repo and ask "is there a universal package, if not is there one specific for my platform"

(while i got the rant ready) Another thing that is random is the artifact name. The uniqueness key for a maven library is the combination of Group + Artifact. So org.jetbrains/annotations is just different than com.example/annotations. Which makes it a bit of a headache when a different group decides to publish the same artifact and really you'd want to say "okay I see you get some-component both from org.jetbrains and com.example. You need to pick which one you want"

if you play the "rewind time, assume modules always existed" game - if artifact id == module id then you could actually do that

so org.jetbrains/org.jetbrains.annotations and com.example/org.jetbrains.annotations

just a different evolutionary path

AOT'd clojure code would take issue with being on the module path but we don't really distribute AOT things as libraries. Publishing a clojure library would require some new metadata but whatever

I think modules are probably the worst thing ever added late to Java (but would feel differently if they had existed from the beginning). serialization is probably the worst thing added early :)

I think <something> is going to happen with them

go on reddit and look for the posts from ron pressler (/u/pron98)

sounds excitingly terrible

I have a few ideas on what "Both of these aspects will soon change." might mean, but it sure does read like a threat