noreward-rl
noreward-rl copied to clipboard
Sessions in tmux don't use the "curiosity" virtualenv
First of all, thank you (and your team) for great research and for accompanying it with code.
On the issue:
Running train.py
will start multiple tmux
sessions and there the "curiosity" virtualenv is not used. So unless one installs the same dependencies on the host (but then why to use virtualenv at all), it will error with missing imports or mismatched versions errors.
Did you miss to add instructions that set up the "curiosity" virtualenv in new tmux sessions? Or I'm missing something?
I have encountered the same problem.
The same problem, but can solve it using 'child' (-m in train.py)
@TianyuanYu There should not be any need for child mode. I am able to run it as mentioned in README.
@AdamStelmaszczyk You have to install all dependencies on host machine. After that, tmux is being used on your host so that all workers can run in parallel. All the instructions given in README are to be run on the host machine where you want to run the code (and not client).
You have to install all dependencies on host machine. After that, tmux is being used on your host so that all workers can run in parallel. All the instructions given in README are to be run on the host machine where you want to run the code (and not client).
I did that, I strictly followed the README. It tells to install e.g. numpy
(and whole pip install -r src/requirements.txt
) in the curiosity
virtualenv. Ok, that's typical.
But then, the train.py
is calling tmux
, which opens new bash session and curiosity
virtualenv is not activated there. So one doesn't have numpy
or anything from requirements.txt
there. So Python will error in the workers.
Can you try also passing --savio
flag to train.py ?
No change, since savio
is True by --default
.
I am sorry -- I realized that later.
Can you debug inside your tmux sessions (using pdb or Ipython debugger) as to which version of python is being called inside the tmux window? That should give you hint as to what's going on. I guess it could be due to some PATH
being wrong ..
which version of python is being called inside the tmux window?
It will be Python from the host, since the curiosity
virtualenv is not activated in tmux sessions.
I think this problem was inherited from universe-starter-agent
code: https://github.com/openai/universe-starter-agent/issues/9 (don't know why that issue was closed, it doesn't look resolved in the code)
universe-starter-agent
uses conda
instead of virtualenv
but the issue and a possible solution is the same.
if use anaconda; in train.py def run(): args = parser.parse_args() if args.default: args.envWrap = True #args.savio = True
comment this line
def create_commands(session, num_workers, remotes, env_id, logdir, shell='bash', mode='tmux', visualise=False, envWrap=False, designHead=None, unsup=None, noReward=False, noLifeReward=False, psPort=12222, delay=0, savio=False, pretrain=None): # for launching the TF workers and for launching tensorboard py_cmd = 'python' if savio else sys.executable
use sys.executable instead of 'python'
executable = '/home/ubuntu/github/noreward-rl/curiosity/bin/python' or python is anaconda python.
@AdamStelmaszczyk @wangluo2028 @TianyuanYu
I have the same problem Running train.py will start multiple tmux sessions. How can I solve this problem?