Repository: Farama-Foundation/Metaworld
Issue: [Question] why does reset not use the seed argument?
Root cause: Documentation Deficiency

### Question

Hi, 

I noticed that the seed argument in the reset is not used, and seed() should be used. Is there a reason for this behavior?

PS: I think it would be better to provide a warning or something to users who reset with the seed argument. This is an annoying bug to catch imo.

This is a good question that we should address in the documentation.

The parametric variations per-task are created outside of the `.seed` or `.reset` functions. Using the `.seed` or `.reset` with a seed passed to the function would change the behaviour of the environments in unintended ways. 

@reginald-mclean could you elaborate on this? 

For my use case, I am using metaworld environments for single-task imitation learning. 
I want to 1) have variations in each task and 2) be able to reproduce the results by fixing the seeds during evaluation of a policy and/or data collection. 

initially I would simply do:

```
env = gym.make('Meta-World/MT1', env_name=task_name, seed=seed, render_mode='rgb_array', max_episode_steps=max_episode_steps)

for N  train steps:
# train for a while


# do eval every now and then:
for i in range (n_eval_runs):
   obs,info = env.reset(seed[i])
   # rollout policy and measure performance

```


but this actually resulted in having different variations during each eval.


Now, I added the `env.seed()` call before the reset, and this seems to work fine for my use case.




>  Using the .seed or .reset with a seed passed to the function would change the behaviour of the environments in unintended ways.

As in, it would alter the set of variations (so you would not have the same finite set of variations)? I don't mind that, as long as they are reproducible. Or am I missing something?

> This is a good question that we should address in the documentation.

Would be nice if you could add something to the docs, because the process of going from the `SawyerXYEnv` subclass for each task/env to the actual env that you interact with after calling `gym.make` feels hard to understand. Possibly because I am not using the benchmark in the way it was created (meta-learning), but I think it is nonetheless a fairly standard use case.





During environment initialization, the finite set of variations per task are created dependent on the random seed given in the `env = gym.make` line of the code you provided. When you call `reset` on the environment the `RandomTaskSelectWrapper` will randomly sample one of the variations from the finite set created at initialization to use. 

However, if you call `reset(seed=seed)` you seed numpy separately (within the environment itself) which differs from the finite set of variations created at initialization. With `reset(seed=seed)` you can have an infinite number of variations if you repeatedly call `reset()` after a single `reset(seed=seed)` call. 

`1) have variations in each task and 2) be able to reproduce the results by fixing the seeds during evaluation of a policy and/or data collection.` we somewhat thought of this use case. If you use the code you provided as follows:

```
num_goals = 100 # make this however many variations you want
env = gym.make('Meta-World/MT1', env_name=task_name, seed=seed, render_mode='rgb_array', max_episode_steps=max_episode_steps, num_goals=num_goals)
```

then you would be able to (a) control the number of variations you would like to use, and (b) ensure that given the same seed for creating an environment you create the same set of variations per seed. 

Additionally, if you want to control the order of variations you can add `task_select='pseudo'` to change from sampling from the set of variations to simply iterating over the variations in order. 

@reginald-mclean, forgot to reply to this one. 

Thanks for the explanation, I think it is clear to me now. Would be helpful if this was documented somewhere, I think. 

And maybe a warning could be thrown when attempting to seed during reset, since it wont have any effect?