Epl sandbox about epl

[swsnr]

@rejeep I'm not sure. Imho such a function “fakes” something, which doesn't exist, namely, a stateless package system. But there is no such thing. Let's face it, package.el has global state, whether we like it or nor, and we cannot complete undo state established by epl-package-install.

Most notably, it'll activate the new package, which loads its autoloads. That cannot be undone easily.

I wonder, what you need that for, by the way. Do you plan to provide an API to use multiple Cask environments at once?

I wouldn't like that. It's bound to cause trouble, because however hard we work, the single global state of package.el will leak through our abstractions, and cause trouble. The Emacs library and package system is simply not up to handle this.

Imho, as such we shouldn't offer such a feature. We can provide an API to parse arbitrary Cask bundles, build packages, docs, whatever, but we effectively can only have a single Cask bundle active, and we can easily switch active Cask bundles.

[rejeep]

I'm mostly concerned about external side effects in Cask functions. For example modification of the load-path.

Most functions in Cask now takes a bundle as argument that defines the current Cask project. The problem is that functions operating on a bundle sometimes need to have the bundle as the "active" package.el directory, for example cask-install.

The reason I started thinking about this is that I added a function in Cask called cask-installed-dependencies. To be able to get a list of the installed dependencies, the directory has to be initialized (package-initialize) and this will change the load-path.

I wonder if each function that has side effects should do their own clean up. For example in this function, we would restore load-path, but perhaps not care about internal package.el changes.

I guess, as you say, we cannot be perfect because that's just how package.el works and all we can do is out best. Frustrating though...

[rejeep]

I'm closing this for now and if I can find a better concrete use cases where this would be the best solution, I'll open up the issue again.