Avoid creating folders/files in root (e.g. ~./conda)

[bschilder]

I'm trying to create a number of extensions for reticulate in a new package echoconda. However, the CRAN reviewers have come back and said that I can't have any root files/folders leftover as a product of my package.
RajLabMSSM/echoconda#1

echoconda uses reticulate to install conda, which is the only place I can think of that ~/.conda would be created. And yet reticulate is indeed on CRAN. Do you have any tips for how to avoid this (e.g. creating .conda elsewhere)?

Many thanks,
Brian

PS - I can submit some of these echoconda funcs a PRs to reticulate if you like. In particular, env_from_yaml() I find helpful.

[kevinushey]

I suspect the ~/.conda folder is created by Anaconda itself during installation / use; reticulate itself doesn't do anything.

Honestly, your best hope is likely to avoid evaluating any code that might try to use Python / Anaconda on CRAN (e.g. in tests, examples, vignettes)

[bschilder]

Thanks for the reply @kevinushey.

I suspect the ~/.conda folder is created by Anaconda itself during installation / use; reticulate itself doesn't do anything.

I think you're correct. I suppose what I'm asking is, does reticulate allow users to specify where the ./conda folder gets put when it's created (i.e. while running intall_miniconda) . There is apparently a way to do this in CLI conda, specifically by overriding the envs_dirs and pkgs_dirs default values.

But I can't figure out how that would translate to conda's usage within reticulate. I was looking for some comparable arguments within reticulate::install_miniconda but couldn't seem to find them.

Honestly, your best hope is likely to avoid evaluating any code that might try to use Python / Anaconda on CRAN (e.g. in tests, examples, vignettes)

I'm a little confused by this, isn't that all of reticulate? that would mean any package that heavily relies on reticulate can't be put on CRAN, unless you remove all means of checking that the code works (which seems likely to break).

[kevinushey]

But I can't figure out how that would translate to conda's usage within reticulate. I was looking for some comparable arguments within reticulate::install_miniconda but couldn't seem to find them.

There are probably some environment variables that could be set to control this, but I'm not positive.

I'm a little confused by this, isn't that all of reticulate? that would mean any package that heavily relies on reticulate can't be put on CRAN, unless you remove all means of checking that the code works (which seems likely to break).

Yes, it is. I haven't yet had a conversation with CRAN around what the "right" way to use Python on the CRAN build machines is, and troubleshooting Python issues on CRAN machines is going to be a nightmare for everyone involved. (Unless troubleshooting Solaris build / test failures is your idea of a good time.)

For packages using Python / reticulate, I would strongly recommend using continuous integration services (e.g. GitHub Actions) to test any code that requires a specific installation of Python.

[bschilder]

There are probably some environment variables that could be set to control this, but I'm not positive.

Will let you know how it goes. Testing out something like this to start:

conda_dir <- "./.conda"
  Sys.setenv("CONDA_ENVS_DIRS"=file.path(.conda_dir,"pkgs"),
                   "CONDA_PKGS_DIRS"=file.path(.conda_dir,"envs")
                   )
reticulate::install_miniconda(...)

Yes, it is. I haven't yet had a conversation with CRAN around what the "right" way to use Python on the CRAN build machines is, and troubleshooting Python issues on CRAN machines is going to be a nightmare for everyone involved. (Unless troubleshooting Solaris build / test failures is your idea of a good time.)

That does seem rather challenging. Would be incredibly helpful though since more and more of my packages involve some mixture of languages (usually out of necessity).

Maybe @flying-sheep / @rcannood / @dynverse could speak a bit more to this since anndata seems to have navigated these issues pretty successfully (I use this package quite a bit and it's great!).

For packages using Python / reticulate, I would strongly recommend using continuous integration services (e.g. GitHub Actions) to test any code that requires a specific installation of Python.

Definitely, just recently started doing this for all my packages. My GHA setup, which first installs anaconda via brew, seems to be working pretty well for echoconda.