Aaron Lun

Okay, thanks. I guess I was hoping for a nice solution that would guarantee that Python-dependent functions in client packages can work regardless of what has already happened in the...

Thanks to @lawremi, the persistence problem has been solved by simply setting up a separate R process. This retains the advantage of isolation, as discussed above, while allowing the process...

Yes, if (2) could be handled on the **reticulate** side, that would make life easier. In fact, if (1) and (2) are provided by **reticulate**, there wouldn't be any need...

Based on the commentary above, I have added `basiliskStart()`, `basiliskRun()` and `basiliskStop()` to provide an abstraction layer under which **basilisk** attempts to choose the best way to do things. In...

Some investigation indicates the size is due to the installed packages, which get installed fresh for every virtual environment, so it's not a symlink issue. The cleanest solution is probably...

@vjcitn The proposed solution is active as of 8b319f3ffcf13b2fde89d2b5473bdc50fc7232d2 and works pretty well for me: ``` $ du -sh basilisk/ son.of.basilisk/ 624M basilisk/ 54M son.of.basilisk/ ``` This shifts the content...

> the greater the compatibility between packages Well, **basilisk** doesn't make any statements or guarantees about Python-Python compatibility across R packages, nor do I feel that would be a common...

**basilisk** now has support for lazy installation of "core" packages. The deal is this: 1. When **basilisk** is installed, it only pulls down _miniconda_. It also contains an in-built list...

> maybe my development pattern (devtools::document() inside source to generate man files) is obsolete? I see this too. Don't know why it happens... guess it's due to some `document()` magic....

The final piece is now in play. **basilisk** will create a virtual environment that is transparently used by any client package that does not require Python packages outside of `core_list`....