Ever since the first version of basilisk, we've relied on conda for managing both the Python version itself and the various packages that are installed. This has worked well for a long time but is under strain due to GLIBCXX versioning issues (see #21) that arise when conda's system libraries are incompatible with those used by R. Our current duct-tape solution is to use a fallback R environment controlled by conda, but this has severe restrictions on the code that can be passed to it.
The real solution is to use a Python that is built in the same environment as R. Historically this has been difficult as it would require an explicit SystemRequirements, which is not user-friendly. (Or multiple such requirements, if different basilisk packages require different Python versions.) Fortunately, reticulate now provides bindings to Pyenv so that custom Python versions can be easily installed with user permissions. I hope that this should eliminate a major source of GLIBCXX version errors without the need for a fallback environment. It should also make life easier for client package developers, who can just use pip directly on their virtual environments.
From the basilisk side, this might be an "easy" change as everything is abstracted away under a BasiliskEnvironment anyway. (A rare case of foresight, given that the very first prototypes of basilisk alternated between conda environments for Windows and virtual environments for everything else.) It would allow us to get rid of basilisk.utils, as reticulate handles all of the Pyenv configuration; and it would allow us to get rid of the fallback and activation code, which are no longer necessary.
Ever since the first version of basilisk, we've relied on conda for managing both the Python version itself and the various packages that are installed. This has worked well for a long time but is under strain due to GLIBCXX versioning issues (see #21) that arise when conda's system libraries are incompatible with those used by R. Our current duct-tape solution is to use a fallback R environment controlled by conda, but this has severe restrictions on the code that can be passed to it.
The real solution is to use a Python that is built in the same environment as R. Historically this has been difficult as it would require an explicit
SystemRequirements, which is not user-friendly. (Or multiple such requirements, if different basilisk packages require different Python versions.) Fortunately, reticulate now provides bindings to Pyenv so that custom Python versions can be easily installed with user permissions. I hope that this should eliminate a major source of GLIBCXX version errors without the need for a fallback environment. It should also make life easier for client package developers, who can just usepipdirectly on their virtual environments.From the basilisk side, this might be an "easy" change as everything is abstracted away under a
BasiliskEnvironmentanyway. (A rare case of foresight, given that the very first prototypes of basilisk alternated between conda environments for Windows and virtual environments for everything else.) It would allow us to get rid of basilisk.utils, as reticulate handles all of the Pyenv configuration; and it would allow us to get rid of the fallback and activation code, which are no longer necessary.