Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No module named 'pettingzoo.utils.all_modules'` #41

Closed
shivarajabi opened this issue Dec 23, 2023 · 15 comments · Fixed by pytorch/rl#1817
Closed

No module named 'pettingzoo.utils.all_modules'` #41

shivarajabi opened this issue Dec 23, 2023 · 15 comments · Fixed by pytorch/rl#1817

Comments

@shivarajabi
Copy link

shivarajabi commented Dec 23, 2023

im kinda stuck

python version:3.9.16
torchrl version: 0.2.1
pettingzoo version: 1.24.2
benchmarl version: 1.0.0

i have this versions but when i try to run :python benchmarl/run.py algorithm=mappo task=pettingzoo/simple_spread i get wired errors like :

ModuleNotFoundError: No module named 'multi_agent_ale_py' and when i tried using pip install 'multi_agent_ale_py i get this error : Could not build wheels for multi_agent_ale_py, which is required to install pyproject.toml-based projects

thanks for help :(

@matteobettini
Copy link
Collaborator

Thanks for reporting this, I will look into reproducing it as soon as I am back to a computer.

In the mean time a few things:

  • the way we install pettingzoo in the CI on linux is pip install "pettingzoo[all]==1.24.1" . If you have installed it in a different way, maybe try this in a fresh conda env
  • I will soon make all MPE scenarios available through vmas (so you can “task=vmas/simple_spread”). This will mean easier installation and pytorch vectorization. Which will lead to more than 10x faster training on MPE
  • This is an error coming from pettingzoo, so i would also open an issue with them. In general I always found it quite difficlt to install that library

@shivarajabi
Copy link
Author

thanks a looooooot for your help, so the results of this vmas MPE and pettingzoo MPE tasks are the same ? i mean the settings are fully identical?

@matteobettini
Copy link
Collaborator

The settings are not fully identical. VMAS MPE tries to be identical to the original repository, while PettingZoo has accumulated some differences over the years.

To see what are the differences in a scenario, simply compare the VMAS MPE folder to the PettingZoo MPE folder

You can also conpare the configuration files in benchmarl to see how the input params differ ( https://github.com/facebookresearch/BenchMARL/tree/main/benchmarl/conf/task/vmas and https://github.com/facebookresearch/BenchMARL/tree/main/benchmarl/conf/task/pettingzoo)

@matteobettini
Copy link
Collaborator

Closing as inactive and I am not able to reproduce the pettingzoo error.

Feel free to reopen and link error details if this still occours.

@andrekuros
Copy link

andrekuros commented Jan 17, 2024

Hi @matteobettini , I am starting to use the BenchMarl, congrats for the job, really impressive. This pettingZoo problem happened to me trying to use on windows when intalling pettinZoo[all], the problem is with the Atari envs when installing the multi-agent-ale-py, is not being able to build the library as required. In my case I needed to start to use the WSL with Ubuntu, install swig and cmake before install pettingZoo[all] and them everything works fine.

The problem is in pettingZoo ( [https://github.com/Farama-Foundation/PettingZoo/issues/1072] ) and only happening with Atari envs instalation. However, despite not using Atari envs in benchMARL, when trying to load pettingZoo envs, classic envs are also loaded, so is not possible to only install MPE and SISL and use benchMARL with pettinZoo on windows.

@matteobettini matteobettini reopened this Jan 17, 2024
@matteobettini
Copy link
Collaborator

Thanks so much for pointing this out and linking the PettingZoo issue.

I really wish a solution to Farama-Foundation/PettingZoo#1072 is found.

On our side, my guess is that we are importing atari (even if not needed) here:
https://github.com/pytorch/rl/blob/d1138e22cea5b81c78dfdb7127530fe812de42d1/torchrl/envs/libs/pettingzoo.py#L911-L941
where, to map the task name to its module, we need to call

from pettingzoo.utils.all_modules import all_environments 

and this imports all modules.

In order to be able to import only the required module from pettingzoo, we would need to be able to make this call without being forced to import all dependencies. Or, in a less optimal alternative, at least be able to call from pettingzoo.mpe import mpe_environments which would return a map from task name to task.

@elliottower any case we can make it possible to obtain the map of pettingzoo tasks without having to import everything and incurring in the windows users issue?

@elliottower
Copy link

Hi @matteobettini, thanks for notifying me and raising this issue, I commented on the other thread but I will take a look into it. I can definitely add a mapping of environment name to module in each environments' init files like you say with mpe_environments, I think that is more ideal than my initial idea proposed on the other issue page (making it so you can import the all environments mapping even if you are missing a requirement), as that could lead to uncaught issues where people think they are iterating through all of the environments (or our CI is trying to) but they are not all found.

@matteobettini
Copy link
Collaborator

Thanks @elliottower for the prompt response. Yes, having a dict per environment module seems doable and at that point all_environments could just be the union of such dicts.

the holy grail for me would be to allow people to obtain all_environments without loading dependencies and load dependencies in a lazy way later during env instantiation.

but i think that, for the current problem, also just the first solution would be enough for me to fix it

@elliottower
Copy link

What exactly do you mean by being able to obtain the all_environments mapping without loading dependencies? Do you mean still having the mapping map from name to module? Because I don't believe that's possible, as to load the chess_v5 module you need to import the chess package. I suppose we could make each environment's dependency imports use a try catch so you can still import the module even though when you try to actually instantiate the environment it fails, but that seems a bit confusing--if a user is able to import an env correctly, they would assume they have the dependencies, and if they are not able to, it indicates they are missing dependencies. I think from a user standpoint it just makes it simpler.

Anyways, I've thrown up a PR to do what we discussed above, thanks again for bringing this up, feel free to take a look if you'd like.

@elliottower
Copy link

By the way I appreciate what you're doing with this repo, great to see some reproducibility and benchmarking in MARL. Hadn't actually seen TorchRL before now either, but that is amazing to see too, feel free to reach out to me again if there are any other issues that come up or feature requests which would make things easier for you guys.

@matteobettini
Copy link
Collaborator

matteobettini commented Jan 17, 2024

What exactly do you mean by being able to obtain the all_environments mapping without loading dependencies? Do you mean still having the mapping map from name to module? Because I don't believe that's possible, as to load the chess_v5 module you need to import the chess package. I suppose we could make each environment's dependency imports use a try catch so you can still import the module even though when you try to actually instantiate the environment it fails, but that seems a bit confusing--if a user is able to import an env correctly, they would assume they have the dependencies, and if they are not able to, it indicates they are missing dependencies. I think from a user standpoint it just makes it simpler.

I am also unsure whether this is possible given the pettingzoo structure, but the idea is

from pettingzoo.atari import basketball_pong_v3 # Works without atari packages (meaning it can be used in all_modules)
basketball_pong_v3.env(**kwargs) # Gives an error saying you don't have atari

By the way I appreciate what you're doing with this repo, great to see some reproducibility and benchmarking in MARL. Hadn't actually seen TorchRL before now either, but that is amazing to see too, feel free to reach out to me again if there are any other issues that come up or feature requests which would make things easier for you guys.

Thanks! That is really nice to hear! I'll definitely reach out and coordinate in the future, so that we can provide the best pettingzoo benchmarking experience possible!

@elliottower
Copy link

elliottower commented Jan 17, 2024

Feel free to reach out via discord as well if you'd like by the way, my username is @b3arodactyl. I was thinking if there are any tutorials using PettingZoo we could add links to them on our site or an official tutorial if there is interest for that (see https://pettingzoo.farama.org/tutorials/agilerl/ or https://pettingzoo.farama.org/tutorials/rllib/ for example)

Edit: and the lazy import you suggest does sound like it may be a useful feature, but I think it's best to keep things as they have been for consistency, and consistency with Gymnasium and other Farama projects.

@matteobettini
Copy link
Collaborator

Yeah we have been thinking about a tutorial explaining turn-based multi-agent learning in torchrl and PettingZoo for a while with @vmoens

If there is interest in that, I might invest some time in it in the future and let you know.

@elliottower
Copy link

That would be awesome, if you need any help looking at the writing copy or anything feel free to reach out. Anyways, this issue should be fixed, will make a new PZ release soon.

@matteobettini
Copy link
Collaborator

I created a PR that should fix the issue pytorch/rl#1817. If any user that was having problems wants to test it, make sure you install the latest pettingzoo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants