I am designing an environment for productive research, i.e. writing, data-analysis, publication, etc.
In order to share the final results with others, I need to find a way to package this and to set up the local installation.
The project depends on Anaconda, so conda as a package manager is available.
It also includes
- Pandoc and some pandoc packages, some will have to be fetched from Github directly because some versions are not available via conda-forge (doable in conda)
- Atom and Atom packages; they should be installed and configured by my script (this works on the CLI via the
apmpackage manager) - Node.js and Mermaid and a few other JS packages, which require
npmcalls - Some file-system-level operations, like deleting parts from packages where I only need a portion from, creating symlinks and aliases etc.
- Maybe some Python code for modifying yaml/json/ini files or reading therefrom.
The main project will reside in a Github repository. It will be fine for users to clone it from there and start a build script locally.
My idea is to write a Bash shell script that
- creates a conda environment based on requirements.yaml for everything that can be done this way
- installs other parts using CLI commands (wget/curl etc.)
- does all necessary modifications using CLI commands, maybe using a few short Python scripts (e.g. for changing or reading JSON or yaml files).
- My local usage will be on OSX Big Sur, Linux should be supported, Windows compatibility would be nice-to-have.
Before I start:
- Is this approach viable? I think it will be pretty transparent, but of course also a bit proprietary.
- Docker is likely overkill for my purpose, and I also read that the execution will be slow on OSX.
- The same environment will likely be installed multiple times on the same users' machine, so it is important that I can control e.g. the usage of existing packages and files via aliases or symlinks. It is not important that the multiple installations are decoupled for the non-python/non-conda parts (e.g. atom, node.js, mermaid could be the same binaries for all installations; just the set of Python packages might vary by installation).
Thanks for your expertise!
