I apologize if this is not the correct site for this. If it is not, please let me know.
Here’s some background on what I am attempting. We are working on a series of chat bots that will go into production. Each of them will run on a environment in Anaconda. However, our setup uses tensorflow, which uses gcc to be compiled, and compliance has banned compilers from production. In addition, compliance rules also frown on us using pip or conda install in production.
As a way to get around this, I’m trying to tar the Anaconda 3 folder and move it into prod, with all dependencies already compiled and installed. However, the accounts between environments have different names, so this requires me to go into the bin folder (at the very least; I’m sure I will need to change them in the lib and pckg folders as well) and use
sed -i to rename the hard coded paths to point from
home<dev account>anaconda to
home<prod account>anaconda, and while this seems to work, its also a good way to mangle my installation.
My questions are as follows:
- Is there any good way to transfer anaconda from one user to another, without having to use
sed -ion these paths? I’ve already read that Anaconda itself does not support this, but I would like your input.
- Is there any way for me to install anaconda in dev so the scripts in it are either hard coded to use the production account name in their paths, or to use
- If I must continue to use
sed, is there anything critical I should be aware of? For example, when I use
grep <dev account> *, I will some files listed as
binary file matches. DO I need to do anything special to change these?
And once again, I am well aware that I should just create a new Anaconda installation on the production machine, but that is simply not an option.
So far, I’ve changed the conda.sh and conda.csh files in /etc, as well as the conda, activate, and deactivate files in the root bin. As such, I’m able to activate and deactivate my environment on the new user account. Also, I’ve changed the files in the bin folder under the bot environment. Right now, I’m trying to train the bot to test if this works, but it keeps failing and stating that a custom action does not exist in the the list. I don’t think that is related to this, though.
I’ve confirmed that the error I was getting was not related to this. In order to get the bot to work properly with a ported version of Anaconda, all I had to change was the the conda.sh and conda.csh files in /etc so their paths to python use ~, do the same for the activate and deactivate files in /bin, and change the shebang line in the conda file in /bin to use the actual account name. This leaves every other file in /bin and lib still using the old account name in their shebang lines and other variable that use the path, and yet the bots work as expected. By all rights, I don’t think this should work, but it does.