Mesa 3.0 beta feedback

[EwoutH]

Mesa 3.0 is in beta! Ask you questions and share your feedback here.

Install with pip install --upgrade --pre mesa

Resources: Migration guide | Release notes | Mesa overview

Our planned timeline:

• Friday 4th: Mesa 3.0 beta 0
• Friday 11th: Mesa 3.0 beta 1
• Friday 18th: Mesa 3.0 release candidate
• Friday 25th: Mesa 3.0 stable release

Update: We’re delaying with one or two weeks. 3.0 stable targeted in the first half of November.

[tpike3]

2 issues on the visualization tutorial:

1- Histogram for the final visual (3rd solara dashboard) does not update with the model, stays a static graph of agent wealth at step 0
2 - The third solara dashboard is very slow if you run everything above it. My inference is that the other dashboards are not actually stopping even though page should be overwriting them.

(I will say the visualizations and dashboard are awesome! I am a big fan)

Thoughts @Corvince?

[tpike3]

I plan on taking care of this (cause really I can just ride @EwoutH coattails), but wanted to document it.

The migration guide has an excellent overview of using different scheduling options and how to create them with Agentset Guide

I am going put them in the How To Guide (without references to the Mesa < 3.0 so that why it can be referenced for new users.

[jtcooper10]

This is a small issue I've noticed, as the fix is easy, but one of the side-effects of wrapping an event callable in a weak ref is that, if the event's scope outlives that callable, then the event silently fails to execute.

The most obvious example are lambdas that are defined from within the callable. A contrived example:

import mesa
from mesa.experimental.devs.simulator import ABMSimulator

class ExampleAgent(mesa.Agent):
    def step(self):
        # this runs! you'll see "message: this works!"
        self.model.sim.schedule_event_now(self.event_callable, function_args=("this works!",))
        # this one doesn't; lambda no longer exists after the scope of the `step()` method ends, which is outlived by the event scheduler
        self.model.sim.schedule_event_now(lambda: self.event_callable("this does not work :("))

    def event_callable(self, msg: str):
        print("message:", msg)

class ExampleModel(mesa.Model):
    def __init__(self, sim: ABMSimulator):
        super().__init__()
        self.sim = sim
        self.agent = ExampleAgent(model=self)

    def step(self):
        self.agents.do("step")

sim = ABMSimulator()
model = ExampleModel(sim=sim)
sim.setup(model)

sim.run_for(1)

>>> message: this works!

Again, this is an easy fix; in my example, just assigning the lambda to the model so that its lifetime is tied to the ExampleAgent object's lifetime suffices. But it might be confusing to users as to why lambdas seem to silently swallow event executions. It's also possible there's already a workaround for this and I missed it.

[quaquel]

It makes good sense that lambda's fail in this example. The lambda is never assigned to a variable so there is no hard ref to it. However, I agree that this should at a minimum be explicitly documented. Thanks!

[quaquel]

and addressed via #2417.

[Corvince]

There has been some talk at various locations about API stability of 3.0 with regards to examples and visualization. Here are my 2 cents:

Examples. Even though some are now bundled with mesa, I think it should be obvious that they are not part of the public API and subject to semantic versioning. We should be able to freely change those without causing a breaking change for mesa itself.

Visualization. I think we can consider the SolaraViz itself stable. Not so much the components/the component creation. There is currently a lot of talk about those with some very good ideas, but just ideas. I see two possibilities

1. Focus the discussion on the API part and create something we are all happy with and can consider stable. Have something working with that API, even if not all features are implemented, or the implementations are not finalized. Then we can work with those without causing breaking changes.
2. Mark the current implementations as "recipes" and thus take them out of the public API/semver. This way users can still use the existing components but we are saying we are working on a stable API for creating components and these are not finalized. Again, I think one of the big advantages of the new solara viz is that users can implement their visualization however they want and just plug it in there.

I am currently leaning towards 2, since it doesn't cause a rush and allows us to release 3.0 soon

[EwoutH]

Examples.

Agreed. They are bundled for convenience, but we can change them at any time. We don’t follow SemVer here.

[quaquel]

Honestly, I don’t see the complexity here.

I see two complications: (1) nothing of it is tested, and I don't like something called stable that is not well tested; (2) there is a difference between adding new components as per some of the ideas in #2389 and locking down the existing API although we might have to change it (e.g., to adress #2428).

[EwoutH]

I agree testing would be nice. I will take a look at our example CI, benchmarks and SolaraViz testing after my thesis is done.

I don't have a strong opinion here, only that I think declaring the whole SolaraViz API a bit overkill.

I'm fine with declaring components or whatever experimental.

[Corvince]

Also note that the module name "components" is a bit misleading, because it consists of 1) solara components that cannot be used with SolaraViz directly and 2) functions to create components that can be used with SolaraViz. I don't think we should expose 1) at all and for 2) they should have a good name and stable API. So we can't just iterate on the API in version 3.x.

Also regarding naming we currently have two files named matplotlib.py and altair.py. This is less then optimal, since it can cause import errors since the names clash with the actual libraries.

[quaquel]

Would something like altair_components and matplotlib_components work better?

[EwoutH]

Hi everyone (and especially @hiltonlamf @pollockDeVis @PeakEwan @peihsunhsieh @AlABarazi @creativechirag26 @rmhopkins4 @DrEntropy @maplesync @PestyVesty @Yureeets @jtcooper10)!

We just released the Mesa 3.0 Release Candidate, our last pre-release before we will tag Mesa 3.0 as stable. We're really curious what you think of this latest version, if anything is inconsistent or missing, if you have any other feedback.

I hope you're willing to test it out and let us know what you think!

[DrEntropy]

We have been using v3.0.0b2 for a while now without any issues. When we moved to RC0 we only had the one visualization issue that was fixed in #2463, which i hope gets included in v3.0.0rc1 or however you work the release procedure ;)

[EwoutH]

Awesome to hear! We have had quite extended alphas and betas, and no other issues came up, so we're going to release Mesa 3.0 as stable this weekend!