Forking a child Emacs process while inheriting the parent's isolated environment

[ikappaki]

Hi @doublep,

If I have an Emacs process started in an isolated environment, is there an established way to fork a child Emacs process that will inherit the isolated environment of its parent?

I have created a test for CIDER some time ago that it required such handling (parent Emacs created a child Emacs process to act as a socket server), but is still bothering me that I had to pass the package-user-dir, load-path and user-emacs-directory to the child Emacs process to inherit the parent's environment:

https://github.com/clojure-emacs/cider/blob/94aff28016c63e4567ceaa3ed1bb7ee9d8eedbbb/test/utils/nrepl-tests-utils.el#L76

The purpose was for the parent process to fork a child Emacs with -l test/nrepl-server-mock.el -f nrepl-server-mock-start using the parents isolated environment.

Thanks,

[doublep]

Not really, because the only time Eldev does is within eldev-emacs command. Actually, there is one more time, in test/package.el, but there are different needs, so I haven't thought about reusing code. Maybe I should look closer at it.

Anyway, if really needed, we can probably break something out of eldev-emacs code so as to be reusable.

But do you want to make nrepl-tests-utils.el dependent on Eldev? I generally prefer "standalone" tests that can be run in whatever way. E.g. for Buttercup tests it is needed that you include (require 'buttercup) for Eldev to be happy. Cask, for example, will run regardless. But I specifically don't want to lift this requirement, because that means you can just M-x eval-buffer RET your test file in Emacs and run tests like that too.

[ikappaki]

Thanks! I've written a little bit of analysis just to ensure I have captured the requirements correctly, and listed possible options I could think of.

I think the general requirement here is (1) to be able to invoke an Emacs subprocess to perform a task while (2) inheriting access to the parent's "libraries", which I define as the emacs-lisp code that can be found in the loadpath and packages.

For example, in the case described above, the child needs access to both the loadpath (for loading the CIDER code being tested) and packages (to find the packages CIDER depends on). I find this to be a valid scenario.

Emacs provides synchronous and asynchronous fns for req#1, but has no facility to support req#2.

In theory, I could (a) ask Emacs dev to support req#2 as a new feature req I could write up, but I have to go through the lobbying process with the devs and not sure yet what form the interface should take (just a list of Emacs argument I could pass to the start process functions?).

Alternatively, the other perhaps more attractive way (b) is I could create a new package published on MELPA that just facilitates req#1 and req#2 though a new interface that just invokes Emacs passing the right command line options to set both loadpath and package in the subprocess. I think this would be acceptable for this case (i.e. to require a new package in the test just for the purpose of invoking an Emacs subprocess as needed by the test).

Or, perhaps (c) we could leverage Eldev knowledge which already does something akin to this, but as you mentioned, do we want the target project code to depend on Eldev? I think if such facility is provided as part say of eldev-util, then we can just include eldev as any other dependency in CIDER tests, and (require 'eldev-util). This makes it more like option (b).

Or finally, I could (d) just leverage eldev-emacs-forward-variables (which I wasn't aware until you mentioned eldev-emacs) to create the command line arguments that inherit the parents environment. It is close to what I have been looking for. Rather than explicitly setting the required env variables (which may change at anytime), I'll just iterate blindly on what is in eldev-emacs-forward-variables.

Thoughts?

I think I will settle for (d) since this is the easier one to implement and within my direct grasp. Though, I'd think a safer place to support the requirements is Eldev with (c).

Thanks!

[doublep]

Sorry, hard for me, because I don't fully understand your needs and don't feel like investigating more. A few notes:

• Variables from eldev-emacs-forward-variables will be passed to all Emacs invocation from under Eldev, not only those used for testing. Up to you to decide if that's ok or not, or even actually exactly what you need.
• I'm willing to accept any reasonable splitting of functionality of eldev-emacs command into a reusable function. If you want to move it eldev-util.el, make sure that it doesn't use anything from eldev.el though (just pass whatever it needs as arguments).