Launching a sub shell in a modified environment instead of sourcing an activate file

[basvandijk]

The following article about virtualenv discusses some of the problems with sourcing a bin/activate file like we do in hsenv. It also discusses a simple solution:

https://gist.github.com/datagrok/2199506

Maybe hsenv could do the same thing?

[tmhedberg]

I saw that article making its way around the Web recently, myself, and did give it some thought in terms of how it relates to hsenv.

I agree with the author in that the presented approach is quite a bit cleaner than the way hsenv and virtualenv currently work. I do think the claim that the existing approach is simply "wrong" is overstating it a bit, however. There are tradeoffs either way.

Anyway, I think it's a good idea, and would go nicely with a hypothetical future 1.0 release of hsenv. However, I have hesitated to make any truly sweeping changes to this project since I started maintaining it due to the fact that Cabal itself is slated to get sandboxing support in an upcoming release. That may end up rendering this entire project moot, which is great, but also sort of disincentivizes my putting significant effort into improving hsenv in the mean time.

I have not done much investigation into what exactly Cabal's sandboxing will provide, and perhaps hsenv and related tools will still be relevant in the future. If that ends up being the case, I'll be much more interested in overhauling this project (in more ways than just the one you're suggesting), but for the time being, I'm mostly just interested in squashing bugs and keeping hsenv working as-is on different versions of the compiler, different OSes, etc.

All that being said, if you or anyone else who reads this wants to take a stab at reworking the activate script, I'd be happy to try it out and merge it in if it looks good.

[dudebout]

The recent work on hsenv to support multiple versions and be cleaner has completely broken the emacs support. The emacs support worked by setting the same variables as the activate script. Now, with the multitude of versions it becomes a problem.

Maybe that gist would solve the problem for tools like emacs.

[tmhedberg]

I'm not sure how it would make a difference. But then again, I'm not an Emacs user and I can't say that I fully understand the intended usage of the Emacs Lisp script. Could you elaborate a bit on why it's currently broken and why activating the hsenv sandbox in a subshell instead of in the existing shell process would make a difference there?

After looking over the script, there is nothing there that, in my admittedly superficial understanding, would stand to benefit from a different method of activation. It looks to me like it just needs to set a few additional environment variables (and maybe drop the usage of GHC_PACKAGE_PATH).

As a Vim user, I just launch the editor from within a shell where the hsenv is already active, and it inherits all the necessary environment variables automatically. Any subprocesses launched from within Vim will likewise automatically see the environment they need in order to work with hsenv. Could not a similar approach work for Emacs? I'm not sure I understand why the special Emacs support script is even necessary to begin with, though I may just not know enough about typical Emacs usage to grok it.

[dudebout]

You are indeed right, this new approach would not likely help. I just read the intro and he talks about GUI working without a shell and I got excited. However, his solution does not improve on that.

That said, the emacs script is out of sync. I started working on fixing that at: https://github.com/dudebout/hsenv/tree/emacs-0.4. The problem with that script is that it doubles up the effort, as you noticed. This problems stems from the fact that emacs is usually run as a daemon. We do not launch it from the directory we work with. Therefore hsenv.el has to set all the variables.

The approach taken there https://github.com/aculich/virtualenv.el seems to be more generic as they source the activate script. I might look into it.

[adinapoli]

Hi all,

I'm not an emacs user but I've played around with the hsenv.el and the fix is easy; instead of searching for ".hsenv_*" or assuming paths with ".hsenv_" we should simply handle both cases, namely ".hsenv" and ".hsenv_".
I patched a quick and dirty hack on my fork of hsenv, works just for the "nameless" one environments but it should give the idea.

As regards of your effort @tmhedberg , definitely keep it up. Your fork is the de facto hsenv standard and is a invaluable piece of my everyday chain ..

so.. Thank you for all your efforts, I think that compliments and congratulations are needed sometimes for the morale :)

A.

[dudebout]

Unfortunately we also need to change the environment variables used. Take a look at the fork I mentionned earlier. It starts in that direction with what I use.

The problem comes from the environment variables depending on your system.

[tmhedberg]

Thanks for all of your contributions as well. I'm glad we're keeping this going too.

If there's more Emacs-related discussion to be had, let's continue it in a separate ticket, as this one is really for the subshell activation issue.

[adinapoli]

+1