Sessions in tmux don't use the "curiosity" virtualenv

[AdamStelmaszczyk]

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?

[wangluo2028]

I have encountered the same problem.

[TianyuanYu]

The same problem, but can solve it using 'child' (-m in train.py)

[pathak22]

@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).

[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).

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.

[pathak22]

Can you try also passing --savio flag to train.py ?

[AdamStelmaszczyk]

No change, since savio is True by --default.

[pathak22]

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 ..

[AdamStelmaszczyk]

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: openai/universe-starter-agent#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.

[zdx3578]

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.

[zdx3578]

@AdamStelmaszczyk @wangluo2028 @TianyuanYu

[zhangjunwang]

I have the same problem
Running train.py will start multiple tmux sessions.
How can I solve this problem?