Dependency issues: tightness and (almost-)circularity

[h-vetinari]

Hi!

I help package things for the conda-forge ecosystem, and we already have some important parts of the Farama universe available there, most notably gymnasium and shimmy.

In order to complete the shimmy optional packages (and thus the gymnasium ones), I'd like to add pettingzoo to conda-forge, but I see a couple of issues when looking at the dependency data here:

• pettingzoo and shimmy have an almost circular dependency on each other, which makes building things very tricky (the only way to break the circularity is to build pettingzoo without its optional dependencies)
  • pettingzoo (with all its optional outputs) depends on shimmy[openspiel], which itself depends on pettingzoo
• pygame (and other libraries) are pinned incredibly tightly - is this necessary? pygame has stayed very compatible over the last releases, and such tight pins make it very hard to co-exist with other packages, much less to pick up new fixes

I'll try to dig a bit deeper, but in case someone's quicker: help would be very welcome!

[elliottower]

Hi, Mark can answer better about conda as he knows about the gymnasium conda install.

About circular imports I can definitely relate to the frustration, it’s a pretty unideal situation but previously we depended on an unmaintained library for Hanabi, honestly we may just be better off taking Hanabi out of pettingzoo classic as it is the only game that still does not have rendering, but I know it’s a difficult benchmark that has research interest so it’s a hard choice. Using OpenSpiel for that environment had been an item on our todo list for years but it was not always planned to use shimmy for it.

Shimmy is used for the multi agent Atari learning environment games as well, but now that the ALE is part of the Farama
Foundation, we are planning to remove the Atari environments from gymnasium and pettingzoo respectively and simply have one documentation site and package for Atari.

We would be open to suggestions about simplifying the dependency tree for sure though, I know we pinned greater than 2.3.0 for pygame due to a specific bug that was affecting our rendering but I think it need not be strict, and I know pygame-ce also works. The Chess requirement we’d like to keep pinned just in the nature of benchmarks, as we don’t want variability in the underlying mechanics of chess within a single pettingzoo version. But I’ve updated it to the most recent version afaik.

Shimmy can be installed itself without any optional dependencies and it doesn’t depend on pettingzoo, same with pettingzoo with no extras not depending on shimmy, but as you said pettingzoo[classic] now requires shimmy[openspiel] which then also requires pettingzoo. We could remove the pettingzoo requirement from shimmy[openspiel] but then it would cause import errors with our type hinting and such. Interdependencies like this are a bit of a pain to navigate but maybe others have come up with slightly better solutions that we can learn from.

[pseudo-rnd-thoughts]

Hey, as I don't maintain PZ, I will just speak to what I think is optimal / makes the most sense.

At its heart, PZ is an API and no more. It provides a specification for implementing multi-agent environments to allow environments and training libraries to speak a common language as such.
Therefore, PZ should have no circular dependency as in the end, it should be at the bottom or close to the bottom of the dependency stack / graph / what you call it.

Therefore, my proposal should be that the environments should be shifted out of PZ such that PZ no longer relies on shimmy and if users want access to the environmens then they must load from shimmy.
This would simplify the issue and provides a simple rationale to avoid this issue in the future.

HOWEVER, this is not the case currently so I don't know a good solution other than biting the bullet or not doing anything.

[elliottower]

Wrote out a reply to this the other day but forgot to submit it. The problem is that Gymnasium (and for example MO-Gymnasium) also has the environments bundled with the API library, I think in order to fix this issue we would have to basically change how all farama projects work and refactor all environments into their own library.

This may be something we want to do at some point, but it would be a large change and I'm not comfortable making that decision, we would want to ask many other third party libraries and researchers and such if they want it--my guess is people would prefer the convenience and have one site for the standard environments as well as the API utilities.

I don't think Shimmy should be the home for it though, as the idea is it's an API conversion wrapper, not a home for environments. It would be better to do pettingzoo-envs or something, but that also feels messy.

Anyways, for the subject of this PR I don't think it's really possible to fix this without the large refactoring mentioned above. Shimmy[openspiel] needs to depend on PettingZoo as people can use that on its own, and it would error out if they didn't have base PettingZoo installed. It is definitely not clean to have PettingZoo environments depend on Shimmy which depends on PettingZoo, but it's not the end of the world IMO, and the bigger problem of Atari environments will be solved in the future when they get moved to the ALE as I said above. As such I'm going to close this as I don't foresee any fix coming in the future, at least from my perspective.

[elliottower]

If there is anything we can do to help with the Conda side of things we would love to do so, but I just don't think there is any feasible option currently.