Remove all library requirements

[Corvince]

Mesa currently ships as a "batteries included" package with requirements for all possible functionality provided. While this is nice for new users, concerns have been raised that mesa is unsuitable for integration into larger projects due to its (possibly unused) dependencies. Upon further inspection all currently required packages are optional.

• click, cookiecutter only used for mesa command
• jupyter not used at all
• networkx only implicitly used by NetworkGrid
• numpy only used for ContinuousSpace
• pandas only used for DataFrame output of the DataCollector
• tornado only used for Visualization
• tqdm only used for batch runner

Those requirements could be put under some extra_requires in the setup.py file and then users could still install mesa with pip install mesa[all] to have everything included.

Steps for this issue would include:

• Update setup.py (decide on name for "all")
• Lazy load all dependencies with helpful error messages if it fails
• Update documentation

But before working on this issue we should decide whether this is a good idea or not

Credits to @rht for starting this discussion in #614

[rht]

• Small dependencies that do not affect the "closure size" and runtime much could be included by default. click, cookiecutter, tqdm are small and fast to load.
• I'd argue that visualization is an essential component (MASON has it by default).

[rht]

MASON also has continuous and network grid (defined from scratch) by default.

[rht]

Tangent: maybe there should be a meta issue tracking feature parity with MASON (source: https://github.com/eclab/mason for easy access). This would be informative for people who are considering to migrate from MASON.

[dmasad]

My sense is that the median Mesa user will want the 'batteries included' installation with all the dependencies. Instead of asking users to specify pip install mesa[all] to get that version, could we specify pip install mesa[min] (or similar) to install the dependency-free version?

[rht]

The [] syntax is only for optional dependencies via extra_requires. The only way possible is to have a package mesa-core that mesa the suite inherits from.

[Corvince]

Yes as rht says this is not possible. A sideways idea would be to create a conda package. I think a lot of new (and probably also more experienced) python users are now using Anaconda. And there we could deploy a 'batteries included' package and keep a minimal base version at pip. That is

conda install mesa
would equal to
pip install mesa[all]

• Small dependencies that do not affect the "closure size" and runtime much could be included by default. click, cookiecutter, tqdm are small and fast to load.

That would put us in the place to decide what are "small" and "large" dependencies.

• I'd argue that visualization is an essential component (MASON has it by default).

It's about making it optional, not removing it. There are a lot of other ways to visualize the results (especially if your doing research and want to create publication ready figures)

[rht]

And there we could deploy a 'batteries included' package and keep a minimal base version at pip.

There would be confusing and non-standard since they are meant to be different installation methods of a package. Additionally, what if a conda package depends on the minimal version?

[Corvince]

I don't know of a standard regarding this (if there is one, I agree we should comply), but its not unusual for the dependencies to differ. The goals of pip and conda are different. You can compare the dependencies for numpy or matplotlib for example (sorry I can't find a list for either of those, but confirmed it by testing locally).

And conda packages can only depend on other conda packages. Even if, how could that be a problem in that direction? The only source of error I can imagine is install the minimal version with pip and then install a conda package depending on the maximal/conda version of mesa. But then the worst case scenario is receiving an error message that tells users they have to install a dependency.

[Corvince]

The [] syntax is only for optional dependencies via extra_requires. The only way possible is to have a package mesa-core that mesa the suite inherits from.

Which probably would be the cleanest solution and would also answer #134 . But I don't see the resources for this split nor the immediate need. I think there would be hardly anyone to only use the core components. And for those use cases it is easy enough to fork the repo and adapt

[rht]

The difference between scipy in conda and pip is that the former has openblas and cython as requirements (https://github.com/conda-forge/scipy-feedstock/blob/master/recipe/meta.yaml), and in pip, openblas is optional. The pip version also has a mechanism not to update numpy if possible (https://github.com/scipy/scipy/blob/master/setup.py#L419-L428). Anyone would have the exact same functioning scipy regardless of the installation method, with performance being the only difference.

One use case of the minimal version is abcEconomics (https://github.com/ab-ce/abce) -- we are planning to reshape the scheduler, the agent verbs, etc (maybe later logging as well but this is too complicated) to be consistent with Mesa / to use Mesa as a basis (cc: @DavoudTaghawiNejad). One plus point of this is that I will port abcE's multi-core scheduling (via multiprocessing) to Mesa. I'm sure there are other projects that may benefit from this deduplication of the ABM layer / API.

[DavoudTaghawiNejad]

there is always the pip mesa --no-dependency option if you don't want to install it without dependencies.

[rht]

there is always the pip mesa --no-dependency option if you don't want to install it without dependencies.

That's for manual install, but there is no such option when being specified in requirements.txt. Nor in Pipfile, toml file (I forgot the filename for this) or other requirements.txt successors.

[jakobaxelsson]

I think I have a clear use case for this. I am running mesa in the browser using pyscript (which in turn relies on pyodide). In pyscript, it is possible to import pure Python packages from PyPI without any problems. However, mesa does not import, and this appears to be due to the tornado dependency. To solve this, I needed to make a local copy of mesa and remove the things I didn’t need. However, this is of course not a desirable solution.

My problem would be solved if the tornado based visualization was an extra. As far as I understand, the mesa version 2+ is anyway moving away from that visualization style, so maybe it would be quite acceptable for most users to specify mesa[tornado] if they wanted that visualization?