Closed jgdavey closed 9 years ago
What would it take to get it fully functional? That is, replace lein -o classpath
and lein repl
.
A few minutes poking reveals boot repl
and boot show --classpath
. The former looks perfect but for the latter what we're really looking for is boot show --fake-classpath
. Maybe we could get that added?
Alternatively, the paths we need appear to be in boot show --env
. But that is starting to sound like a separate plugin.
Yeah, that's why I gave up prematurely. What would you think about a psuedo-fork for boot? This plugin, after all, leiningen-focused. Trying to make it work for both might be more trouble than it's worth.
Someone already attempted it with https://github.com/rkneufeld/vim-boot, but best I can tell haven't solved the hard problems. I do think pushing for --fake-classpath
would be the way to go regardless of to fork/not to fork.
I'll update this PR if and when this gets merged: boot-clj/boot#131
Once boot RC10 is released, the --fake-classpath
option will be available. I've preemptively updated the commits on this PR.
Okay. While we wait on that I will stew on rather a fork or unification makes sense, and if the latter, if a rename is in order.
Also debating if the softly deprecated classpath.vim might have a fresh role to play.
This is working with the latest cut of boot. I've also cleaned up the commit slightly.
Has this been working for you? I am leaning towards a rename. Maybe salve.vim, because Leiningen rubbed a salve on his boots.
Does boot have an equivalent to lein run
? That appears to not be covered by your patch.
It's working, and all the navigation commands are there. FWIW, most of my projects are custom enough (with both server-side and ClojureScript components) that I end up writing a .projections.json
anyway.
Unfortunately, no, there is not equivalent to lein run
in boot. I believe the thinking is that you can easily write boot tasks that run anything, but there isn't a way to run an arbitrary namespace's main
function. Although, if the intention is to fire up a background REPL, boot repl
(or even boot repl -s
) would probably suffice.
Also, nice pull on the salve.
The direction I have been moving my plugins is to use :Console
for REPLs and :Start
to actually run the app. Though I suppose if there is nothing better to run we could use boot repl
for both in this case.
If you were deploying Boot to Heroku, what would the Procfile look like?
Good question. I haven't seen anyone do it, but you could conceived make a boot task to "run" your app. I personally use boot jar
or boot uber jar
to build the whole thing and then just use java -jar app.jar
on my servers. Heroku supports jars as a deployment target, but I've personally never used it.
So after a quick review I think here's what needs to be done.
boot repl
as start task.'makeprg'
in s:activate()
.lein
commands need to be fixed (haven't exhaustively searched).g:leiningen_no_auto_repl
and rename to g:salve_auto_start_repl
. (Backwards incompatible rename is as good of time to do this as any.)Do you have time to start on it? I will probably get to it in the next couple of weeks if not. Once the repo is renamed I am happy to grant collaborator status.
I'll look at this today. Cheers!
BTW I am now thinking the solution to the 'makeprg'
problem is two separate compiler plugins.
I agree. That's how I'm handling it
Okay, I believe I've addressed everything. You can see the branch here: https://github.com/jgdavey/vim-leiningen/tree/salve
Were you thinking of making a separate repo, or doing a github rename?
GitHub renames do redirects nowadays so I will do that.
Had an ancient unpushed commit so I have rebased onto a salve branch of my own. I have some Clojure work on my agenda for hopefully later today and will test further then.
Okay, merged. I will give another week or so before officially committing to a repo rename.
...and pushed.
Other than starting up a background repl, this provides static support when boot is detected.
N.B. It works when the repl is already running.