planck

Planck ClojureScript REPL
slipset 2016-04-05T13:14:23.000007Z

I just threw this together https://github.com/mfikes/planck/pull/272

mfikes 2016-04-05T13:15:18.000009Z

@slipset: Yeah. I’d almost prefer Planck support the concepts intrinsically. Meaning as simple as an option specifying a dependencies vector.

mfikes 2016-04-05T13:16:18.000010Z

This is one of those “interface” issues where it is probably much more important to get the interface right than the details on how it is actually implemented.

slipset 2016-04-05T13:16:38.000011Z

Yeah, I totally agree. Just threw something together to start a discussion

mfikes 2016-04-05T13:16:42.000012Z

Cool

mfikes 2016-04-05T13:17:30.000013Z

If you decomplect, it seems like there is (a) saying you depend on a lib, (b) retrieving that lib, (c) dealining with transitive deps of that lib.

slipset 2016-04-05T13:17:32.000014Z

What I’d like, personally would be if planck by default used whatever it found in some directory as its classpath

slipset 2016-04-05T13:17:51.000015Z

I agree.

slipset 2016-04-05T13:18:11.000016Z

What I’d like to solve is, I’ve got all my dependencies somewhere, please load them

mfikes 2016-04-05T13:18:22.000017Z

Yeah, definitely, consuming .m2 deps is more painful right now than it should be.

slipset 2016-04-05T13:19:00.000018Z

This way I could use some other tool, like myself, to get the required libs in said directory

mfikes 2016-04-05T13:20:13.000019Z

I think there is something appealing about being able to simply include an opt that says that you depend on a certain version of a lib.

planck -m ‘[[foo “0.1.0”][bar “0.2.0”]]’
with Planck just “figuring it out”.

mfikes 2016-04-05T13:21:10.000020Z

Perhaps an additional option to override ~/.m2 as the Maven repo location.

mfikes 2016-04-05T13:21:15.000021Z

(Just thinking out loud.)

mfikes 2016-04-05T13:22:29.000022Z

Honestly, the scary thing about this for me is the complexity that I presume is associated with actually implementing the download portion properly. There must be a lot of stuff in lein that understands ~/.m2/settings.xml, and lots of crap that could fail when dowloading.

slipset 2016-04-05T13:23:01.000023Z

Yeah, problem is, (which might not be a problem), I chased the dependency resolution code in lein down to some java-libs

slipset 2016-04-05T13:23:24.000024Z

which means that you’d have to reimplement dependency resolution in cljs if you’d want for this to work without using java

mfikes 2016-04-05T13:23:35.000025Z

Ahh… interesting.

mfikes 2016-04-05T13:23:49.000027Z

Didn’t know lein worked that way. So, even lein is delegating that scary work.

slipset 2016-04-05T13:24:28.000028Z

yes, at least that’s what I found, but I could be reading the wrong code right, or even the right code wrong.

slipset 2016-04-05T13:24:49.000029Z

But, that’s sort of why I gave up on the whole dependency resolution thingy for planck/clojurescript

slipset 2016-04-05T13:27:25.000031Z

But, again, a nice start would be if you outsourced the dependency resolution and downloading to something else, and just had all the libs you wanted in a directory, and that planck could load deps from that lib.

slipset 2016-04-05T13:27:51.000032Z

planck —dependencies-lib=./lib/

mfikes 2016-04-05T13:28:13.000035Z

I guess a lot of people already have stuff in .m2 that they just want to easily depend upon.

slipset 2016-04-05T13:28:25.000036Z

Yes, but I have so much more :simple_smile:

slipset 2016-04-05T13:28:59.000037Z

like spring and stuff from java projects

mfikes 2016-04-05T13:29:31.000038Z

I wonder if

planck -c `lein classpath`
itself works for many people

slipset 2016-04-05T13:30:36.000039Z

yes, but then you need java :simple_smile:

slipset 2016-04-05T13:31:11.000040Z

and the startuptime would be rather slow

slipset 2016-04-05T13:31:57.000044Z

I am being difficult here, I know.

mfikes 2016-04-05T13:36:37.000045Z

Yes… that’s why I don’t like using lein classpath… latency