Closed grabear closed 6 years ago
I definitely agree on using something or implementing things in terms of the best practices for R.
Are our goals to make this something people can install from source? A binary?
I just wanna is pypi lol.
Installing R packages is the first priority #2. It depends on configuration and installation of a virtual environment for various R version #13, which depends on our directory structure #9. All of these items have various dependencies list in this Epic (#8) and the tagged issues in this comment. Most notably pipenv, click, and cookiecutter.
Here are the current packages and tools that we will need to use in order to develop the CLI:
- Python package management with poetry
- R virtual environments with pipenv
- For separate R version that exist globally/locally.
- For separate R version that don't exist.
- For various projects
- For miniCRAN repositories
- Windows rpy2 implementation with pipwin
- For installing R packages
- Filesystems with cookiecutter
- CLI development with click
I've intentionally left the coding part undone at this point in order to research as many different ways of doing this as possible before reinventing the .whl. I think we should take a look at the poetry project or flit project being used for python packaging, and take some cues from them. In particular the pyproject.toml functionality that's was implemented in PEP518.
I created an issue on the poetry repo and got some pretty good feedback on this:
I think it's also important the we use as much native packrat functionality as possible. It will save us a lot of time, as we will want to comply with proper R configuration. It would be nice if we could convince packrat to utilize the .toml files as well via rcpptoml.