FWIW: The last couple of months I’ve been involved in a project at work which has required some green-field coding.
I’ve taken the liberty of implementing it in Clojure, but the reason I bring it up here, is that the stuff I’ve been writing has mainly been command-line things with a core.clj, so in theory I could have done it in Planck.
Here are some of the reasons I didn’t:
1) I don’t “trust” Planck enough in terms of knowing that I could get the job done. This is more in terms of libs available than Planck itself.
2) Libs available. I’ve been using the following libs:
- org.clojure/data.csv
- org.clojure/data.zip - org.clojure/data.xml
- cheshire
- clj-http
3) Some of the projects had to interop with java, so Clojure was a given.
My point here is not to pick on Planck, but to give an idea of why I chose not to use Planck.
Also, for some of the stuff I made, I needed to let other people run my code, so I distributed an uberjar. I do not know how to do that in Planck.
@slipset: fascinating! My story is strikingly similar to yours. My stuff is still JVM based and just got published https://github.com/IBM-Watson/kale
seems like kale is a bit more involved than what I’ve been tinkering with 🙂
The above makes you wonder if Planck should provide a -j / —jar
option and do whatever is appropriate in that case. (https://github.com/mfikes/planck/issues/107 or other things)
@mfikes: I guess what I’m looking for, in addition to the missing libs, is some tooling that packages stuff together and creates an executable
Right. Even in the Kale example above, it resorts to alias 'kale=java -jar /Users/ba/Downloads/kale-1.4.0-standalone.jar’
Then your “executable” is kale
.
yes, that’s what I’m doing as well
but it would be cool with a planck-tool make-executable kale
or something
Perhaps if Planck itself could be treated as a native library, then native tools could be built.
anyways, got to pick up the kids in the kindergarten.
Right now, you’d have to fork Planck, revise it a bit to produce what you want, and then spit out your custom binary. 🙂
OK, later on 🙂
oh, but it could be a shell-script 🙂
🙂
Planck even has the “bundling” logic worked out. So all of the “uberjar” could be in the binary. 🙂
I really don’t care about the implementation, I just want to be able to hand 'a thing' over to my colleague that he can run.
Yes. Ideally that thing would be a monolithic self-contained binary. Like what you get when you download Planck from the site.
and, since it’s Planck, preferably without invoking java.
That’s a cool idea. Then you could essentially create self-contained command line tools.
Exactly
I wonder how hard it would be to have planck
have an option to essentially produce a copy of itself, with additional bundled artifacts, where that copy runs a -main
. That way shipping planck
binaries could be used to create standalone executables.
planck -c some-artifacts -m kale.core —create-binary kale
then
./kale a b c
would essentially execute as if you had done
planck -c some-artifacts -m kale.core a b c
where kale
could be executed on a box that has nothing else on it except OS X.Sounds cool!
Sorry, Bruce for having hijaked kale
as the example 🙂
I’ve been enjoying seeing the kale
name get used in this discussion 😄
And, if you could then run kale --socket-port=1337
which in addition to starting the app also starts a socket REPL in the app, I'd be blown away.
Actually, this is starting to look like something I’ve wanted for a while, which is the ability to dump a Clojure image. http://stackoverflow.com/a/585784/9422