automatically installing lein

[Phillip Lord]

Following on from the "why is this so difficult" thread that some of you
will have read, it seemed to me that one way to make things simpler was
to give nrepl the ability to install lein. The end intention would be to
obviate the need for wget/curl and putting stuff into the PATH which is
a barrier for windows users.

So, my initial attempt at this is here:

https://github.com/phillord/nrepl.el

I've added a "self-install" function, and modified nrepl-server-command
to fit. I've removed the invoke through shell option because lein is
always invoked via full path.

This falls short of my objective however, because it runs "lein
self-install" which, of course, needs wget/curl. One solution would be
to duplicate the logic in lein.bat/lein.sh but this is likely to break
over time. My other thought was to add to lein an "emacs-self-install"
option. This would return a form:

(url location)

which emacs could parse and then do the downloading.

Is there any interest in incorporating this? I haven't done the work it
would need on leiningen, and I haven't tested on windows yet, cause I
don't have a machine handy. So, this is kind of proof-of-principle.

Phil

[Phil Hagelberg]

Phillip Lord writes:

> This falls short of my objective however, because it runs "lein
> self-install" which, of course, needs wget/curl. One solution would be
> to duplicate the logic in lein.bat/lein.sh but this is likely to break
> over time. My other thought was to add to lein an "emacs-self-install"
> option. This would return a form:

I have a port of bin/lein from bash to elisp here:

https://github.com/technomancy/lein.el

It's designed to allow use of Leiningen from eshell using nothing but
elisp and the leiningen standalone jar. I've started on self-install
functionality there as well, though there are still issues around it as
well as around the general async approach of eshell.

Happy to get more help on it. I think that's probably a better place for
this kind of thing than nrepl.el.

-Phil

[Phillip Lord]

That sounds perfectly reasonable, at least assuming that nrepl can also
use this to launch lein for its own purposes. I guess then the two
packages would depend on each other.

I've pushed changes up to nrepl.el which achieve this anyway, because I
wanted to see if it works.

https://github.com/phillord/nrepl.el

The answer is nearly. Unfortunately, the getting lein.bat fails on my
windows box. The problem is that lein.bat comes from https, which
requires GnuTLS. So, you have to install that library, and set the path
so emacs can find it. Sort of defeats the point. I tried getting
lein.bat from the equivalent http, but it just redirects.

Oh dear, making things as easy as possible is sometimes harder than
necessary.

Phil

[Phil Hagelberg]

Phillip Lord writes:

>> Happy to get more help on it. I think that's probably a better place for
>> this kind of thing than nrepl.el.
>
> That sounds perfectly reasonable, at least assuming that nrepl can also
> use this to launch lein for its own purposes. I guess then the two
> packages would depend on each other.

I'd rather have lein.el enhance nrepl.el when it's installed rather than
introduce a dependency. nrepl.el could suggest installing lein.el if it
notices that Leiningen's not installed already once lein.el is stable
and suitable for everyday use. Circular dependencies are always more
trouble than they're worth.

> The answer is nearly. Unfortunately, the getting lein.bat fails on my
> windows box. The problem is that lein.bat comes from https, which
> requires GnuTLS. So, you have to install that library, and set the path
> so emacs can find it. Sort of defeats the point. I tried getting
> lein.bat from the equivalent http, but it just redirects.

I think newer versions of Emacs bundle TLS libraries in-process instead
of calling out to them, so that might help?

-Phil

[Phillip Lord]

Phil Hagelberg <ph...@hagelb.org> writes:
> Phillip Lord writes:
>
>>> Happy to get more help on it. I think that's probably a better place for
>>> this kind of thing than nrepl.el.
>>
>> That sounds perfectly reasonable, at least assuming that nrepl can also
>> use this to launch lein for its own purposes. I guess then the two
>> packages would depend on each other.
>
> I'd rather have lein.el enhance nrepl.el when it's installed rather than
> introduce a dependency. nrepl.el could suggest installing lein.el if it
> notices that Leiningen's not installed already once lein.el is stable
> and suitable for everyday use. Circular dependencies are always more
> trouble than they're worth.

Yes, I agree. But, the level of dependency between the two packages that
you are talking of is significant enough, that I wonder whether there
really are two packages there. Still, regardless, it would be a good
thing to do.

I am still confused by the last form in nrepl-server-command

(if (or (locate-file nrepl-lein-command exec-path)
(locate-file (format "%s.bat" nrepl-lein-command) exec-path))
(format "%s repl :headless" nrepl-lein-command)
(format "echo \"%s repl :headless\" | eval $SHELL -l" nrepl-lein-command))


Under what circumstances will this find lein that they others don't? I
can think of only one, which is when someone launches Emacs outside of
their login shell. It effectively means that nrepl.el doesn't pick up
that lein is missing cleanly. AFAIK, it also means that emacs requires a
restart to pick up a newly installed lein.

>
>> The answer is nearly. Unfortunately, the getting lein.bat fails on my
>> windows box. The problem is that lein.bat comes from https, which
>> requires GnuTLS. So, you have to install that library, and set the path
>> so emacs can find it. Sort of defeats the point. I tried getting
>> lein.bat from the equivalent http, but it just redirects.
>
> I think newer versions of Emacs bundle TLS libraries in-process instead
> of calling out to them, so that might help?

It would, if it is the case. Currently, though, the easiest solution I
have found is to dump the GnuTLS DLLs into the Emacs directory.

I have pushed some more changes to my nrepl.el fork, for Emacs on W32.
I'll send a pull request if there is interest!

Phil

[Phil Hagelberg]

Phillip Lord writes:

>> Circular dependencies are always more trouble than they're worth.
>
> Yes, I agree. But, the level of dependency between the two packages that
> you are talking of is significant enough, that I wonder whether there
> really are two packages there. Still, regardless, it would be a good
> thing to do.

Not really; most people using nrepl.el will use it without lein.el
because not everyone likes eshell, and even those that do want to be
able to use Leiningen from a regular shell.

> Under what circumstances will this find lein that they others don't? I
> can think of only one, which is when someone launches Emacs outside of
> their login shell.

Yeah, unfortunately this is a fairly common problem on OS X. It's
difficult to add to your $PATH in a system-wide way on OS X, so
user-space installations of Leiningen will be invisible to Emacs
launched from the GUI without this.

-Phil

[Phillip Lord]

Phil Hagelberg <ph...@hagelb.org> writes:
> Phillip Lord writes:
>
>>> Circular dependencies are always more trouble than they're worth.
>>
>> Yes, I agree. But, the level of dependency between the two packages that
>> you are talking of is significant enough, that I wonder whether there
>> really are two packages there. Still, regardless, it would be a good
>> thing to do.
>
> Not really; most people using nrepl.el will use it without lein.el
> because not everyone likes eshell, and even those that do want to be
> able to use Leiningen from a regular shell.

Was thinking the other way around; that is everyone using lein.el will
probably be using nrepl.el. People using nrepl.el who don't want to use
eshell could just not use it.

>> Under what circumstances will this find lein that they others don't? I
>> can think of only one, which is when someone launches Emacs outside of
>> their login shell.
>
> Yeah, unfortunately this is a fairly common problem on OS X. It's
> difficult to add to your $PATH in a system-wide way on OS X, so
> user-space installations of Leiningen will be invisible to Emacs
> launched from the GUI without this.

Ah, macs. I've put some code into my fork to cope with this, but only on
Macs, so that the absence of lein on other OSes can still signal an
error.

Phil