Took me a while to work out what args it needed 😅 it also seems to depend on lein implicitly, I wonder if that's easy to refactor out.

There's some fun code in that file that resolves require order and spits the paths out into an EDN file too. Might come in handy!

awesome. will have a proper look

re leiningen: it is still a leningen plugin. took some steps to prepare to move away from that. so all the leiningen specific code is in https://github.com/benedekfazekas/mranderson/blob/master/src/leiningen/inline_deps.clj

there is also a dependency in mranderson.util

on leiningen logging. bit silly tbh but easy to eliminate

so the endgame will be to move the lein specific stuff into a different (sub)project and keep/release the core separately

that said, i guess if i get rid of the dependency in mranderson.util you could actually exclude leiningen maybe…

also looking at this, perhaps expecting the inline-dep meta on the deps in mranderson.core is not really necessary. could assume that deps passed in here are all for inlining. and do the filtering in the leiningen specific code

Yep, I'm fine with it being a lein plugin for now, happy to accept any extra baggage because of that 😄 a core release without lein/deps would be neat though. I kinda like the logging output since it lets you know exactly what it's doing, but maybe it'd be cool to make that configurable in some way. I guess you have to break down the functions so more so you can call them all with your own logging in between steps.

The meta could probably be dropped too, you're right. Move the filtering up a little bit to the lein part.

just to understand the process here — so when i install conjure as a vim plugin it runs the mranderson step during compile, right?

Yep, on install

It's not used at runtime, I prep the dependencies ahead of time.

and then it gets injected into the prepl, right?

together with the rest of the code but not inlined/shadowed, or?

The other thought I had: I wonder what format the deps and their data should be in, because the current one is very lein-ish (which isn't bad!). I wonder if it was made more generic would you want a generic format, or maybe just translate the tools.deps format to a lein-like one.

It gets injected in upon connection at the moment in reverse dependency / require order, correct.

also the versions in injected-deps.edn does not really change between installs, or?

That's just a static file that's super obvious so people can see it if working with it. Rather than it being buried in conjure.munge.main

And so I can base circleci caches on it's hash 😬

I'm referencing the full mrandersonified namespace names in conjure.code which is where I generate code strings to be fired across the prepl on the fly.

Right now, that's just compliment, but that will include tools.namespace for reloading and orchard/cljs-tooling for a bunch of things soon.

re.format: good point. suppose it is tied to pomagranate/aether atm that i use to resolve those deps

Which tools.deps can also do?

It's almost like you want a small core that just does the renaming / moving part.

And two wrappers that use lein and tools.deps respectively

ah i have not found this bit. because it is all in strings obviously

can see those references now

That code will be moving to template files eventually I think. It serves it's purpose for now.

(I'm using string templates because I can't use reader conditionals in some cases which is something I patched in clojure but might not be released until 1.11)

yeah, reminds me of old cider (was *not* called cider) days

was done the same way and the it was changed to use this nrepl middleware architecture we use now

I hope I'm not repeating toooo many of the old mistakes.

i can’t really say. don’t know (neo)vim enough. guess @U09LZR36F would be able to say 😉

i definitely did not mean you did

you are right saying that tools.deps can do the same. i should probably rather use it instead of pomagranate

I'm definitely reinventing a wheel 😅 buuuut I'm taking that wheel in a different direction since I have opinions on how this tooling should work, behave and be extended.

a cheeky self plug here: https://github.com/benedekfazekas/trin

may be of interest. although in PoC status atm

👀 this is interesting!

should be able to support things for locals even in its current status. although even that is very alpha

so using tools.deps is a very good idea actually

i might self file a ticket

thx

Haha no problem!

I'm sorry I haven't submitted the PR to pull things apart myself, I just realised I can get by with what's there right now.

Hopefully my tinkering has prompted ideas at least, and I'll be happy to try stuff out or help where I can.

> It’s almost like you want a small core that just does the renaming / moving part. this is essentially mranderson.move

and plan to put that in a separate lib at some point: https://github.com/benedekfazekas/mranderson/issues/37

> I’m sorry I haven’t submitted the PR to pull things apart myself, I just realised I can get by with what’s there right now. i guess this is also good news 🙂

cheers

wrt trin: It fits my approach to Conjure. I want a bunch of small tools I wire up over a regular prepl connection, nothing special on the other end. So I will keep an eye on it if I go to add refactoring tools (something I've never really used...) wrt issue: Yep, saw that one, would definitely be useful! I did like the fact that I could do so much with so little code with the current mranderson though, it's a great tool. Thank you very much for it!

welcome 🙂 glad you (happy to) use it

the more i think about the way how your embedded clojure strings have references to the prefixed deps changed by MrAnderson. This is quite brittle as they are disconnected. eg MrAnderson does not know about those strings I suppose. guess this is what the warning in injected-deps.edn file is about too

wondering how this could be fixed. I appreciate that practically this may not be a big problem

maybe if you put those strings into separate files as you want to anyway i suppose. they need to be .clj files too and let MrAnderson know about them…

Yeah, it's pretty brittle but it's all under my control. If a mranderson version bump breaks them that's my problem to fix, I know the risks ☺️ I was considering writing some files out that depended on those libs and then compiling but it complicates the development workflow a fair bit. Not sure how I'd manage with the ClojureScript and Clojure implementations at that point.

I could make it a little more generic by spitting out a map from the compile step that contained the old symbols as keys and the new symbols as values. Then my template code could look up the namespaces it wanted in there.

sounds workable actually. yeah i realise although brittle it might not cause immediate problems

Some meta output out of mranderson, either as it runs or at the end could be useful. "here's the files I read and wrote and what I renamed inside them". I could then do my ordering work with tools.namespace on that output and spit out the full report to use in the future.

Not a feature request really, just a note that internal information like that could be useful in my specific context.

makes sense. i might create a ticket to think about it