Clojurians Log v2

@hlship FYI What was the other library coord @p-himik

Oh, the clj-commons version...?

org.clj-commons/pretty, yeah.

Ah, because the clj-commons version also has these two nses https://github.com/clj-commons/pretty/tree/main/src/io/aviso which overlap with the old pretty lib.

For a while I segmented out the io.aviso.repl bridge code into a secondary library, but that ended up causing some problems inside Nubank's thousands of repos.

Pretty 1.4.4 is ancient right?

Well, maybe hundreds that had a dependency on the old library.

Dates back to Jun 2023.

(ancient = about three years old)

In my case, eftest still depends on it. On 1.3, even. :) But seems to be fine with 1.4.4.

@hlship But why have that bridge at all? Why not approach clj-commons/pretty as a completely new library, so that it and io.aviso/pretty could co-exist safely?

The idea was to do exactly that -- make it easier for the two to coexist so that a bump in dependencies would remove io.aviso and add clj-commons, and you could opt into the bridge if you wanted compatibility. I'm trying to figure out why I moved the bridge code back into the main lib.

It was some kind of Nubank headache that had to be addressed quickly.

That's not "co-exist", that's "eliminate". :D If something wants io.aviso/pretty, it should get it. Otherwise it's a nasty dance with :exclusions to make sure that the clj-commons version comes first.

In other words, if a user ends up having two x.clj files on the classpath, how do they make sure that the "right" one gets loaded? What even is the "right" one when the namespaces don't have the same API?

I'm not saying you are wrong, because that's exactly what I initially implemented. I'll look into bumping pretty to address this (strip out the bridge code again) and I'll straighten things on the Nubank side.

the problem with installing manually into .m2 is it can lead to weird bugs (eg. production code accidentally requires the lib, which nobody else has in .m2)

Curious if there are alternate solutions I'm not considering or if this is worth an ask.

that makes a ton of sense to me. :dev-stuff {:local/root "/User/steven/projects/dev"}} and then using it everywhere seems totally fine to me

I've been doing as @dpsutton suggests for a few years now and it works fine. I have the following alias added to my .clojure/deps.edn

:mydev {:extra-deps {com.phronemophobic/mydev {:local/root "/Users/adrian/mydev"}}}

also don’t sleep on load-file

classpaths are cool. But especially with add-deps stuff you can call that and then define a namespace with helpful stuff

:llm-repl   {:extra-deps {local/llm-root {:local/root "/Users/dan/projects/clojure/llm-repl"}}}

or actually not entrypoint but contains a socket repl implementation

Yeah this worked. For some reason I thought absolute paths weren't supported but looks like they are. Thanks.

Oh, I remember my dilemma. I maintain the same config for all my dev machines but the username is different. But that seems like a separate problem, not a deps issue.

I can solve that disparity elsewhere.

the location varies? /Users/<whoami>/projects/…?

Correct

ah. yeah i’d put some commented out marker in there to fix it up. or could use proper rewrite-clj to do it for real

if it's a small number of potential locations, just add all of them 😄.

multiple local roots? and only one would resolve?

I think that should work.

Definitely not doing that because the error noise will pollute genuine troubleshooting. Yeah there are config management tools out there that can handle it. I'd just need to template the edn file.

I would install the library normally into ~/.m2/repository.