Release v2.0

[jackiekazil]

Last release was v1.21
Prep v2.0 Release

• Identify anything that needs to be pushed thru/completed for the release
• Tag with milestone Release v2.0 #1707
• Update history
• Submit PR for merge
• Merge PR
• release

[jackiekazil]

@tpike3 I haven't been tracking as well as you.
Is this a minor or patch? Should we be going from 1.2.1 to 1.2.2 OR 1.2.1 to 1.3.

RE: Milestone - The milestone was called "next release" I renamed to v1.2.2, which we can change if you think it should be 1.3. Do the attached PRs look like everything between v1.2.1 & where we are now?
Wasn't 2.0 stuff merged in to main? (If so, we should just push for 2.0 out the door -- It is much easier than trying to separate the two.)

[rht]

There was 1 breaking change merged. I think we should merge the rest and push for 2.0.

[tpike3]

I forgot about the 2.0 merged stuff.. let's just do 2.0.

[jackiekazil]

Thank you @rht and @tpike3 -
Agreed! 2.0 it is!
I will start prepping.

[jackiekazil]

i updated the title of this ticket.
Also created this branch - https://github.com/projectmesa/mesa/tree/v2.0
First steps are to...

1. Identify anything that needs to be merged/pushed thru. Since this is a major release, it is important for us to do this. Is there anything that breaks Mesa that is close to being done that we can/should include in 2.0?
2. Tag everything in 2.0 with the milestone & untag anything that isn't getting included -- https://github.com/projectmesa/mesa/milestone/33

[rht]

We should deprecate grid[x][y], keeping only grid[x, y], so that the API is independent of the implementation detail, that it doesn't have to be a list of list (see #815). Either we go straight to removing it in 2.0, or create a deprecation notice, and then remove it in 3.0. It is safer to do the latter.

[tpike3]

We should deprecate grid[x][y], keeping only grid[x, y], so that the API is independent of the implementation detail, that it doesn't have to be a list of list (see #815). Either we go straight to removing it in 2.0, or create a deprecation notice, and then remove it in 3.0. It is safer to do the latter.

I agree, we should deprecate and then create the notice and remove in 3.0

[rht]

I think it's fine to keep grid[x][y]. NumPy supports it, and any other backends could be made to support it with a brief implementation.

[jackiekazil]

Update on status: Last PR was merge... now history needs to be updated, merged, and we can deploy.

[jackiekazil]

Just when you think we are close...

We have a problem with the release -- I got a HTTP 400 Error from test.pypi

ERROR    HTTPError: 400 Bad Request from https://test.pypi.org/legacy/
         Invalid value for requires_dist. Error: Can't have direct dependency:
         'mesa-models @
         git+https://github.com/projectmesa/mesa-examples@db2ec0383eb3b1868e91c8
         28101e84cce97bbb63'

Doing some reading on this, I feel like this is the best summary article & assuming that -- option 3 is what I am leaning towards. https://til.dchan.cc/posts/11-29-2022/

@rht - let me know your thoughts, other ideas?

[rht]

There are 2 options:

1. Move the Jupyter viz code to Mesa core. It's only 1 file after all
2. Publish mesa-models to PyPI

@Corvince objects to option 1, because only stable code should be in Mesa core. But this convention is not explicitly said nor known to the users. I have seen projects post 1.0 that adds experimental API/features (see e.g. Seaborn) just fine. The caveat of option 1 is that the models are not automatically included in the mesa package, which means I have to modify the tutorial to install from the mesa-examples Git repo.

[rht]

Ah, option 3 in that blog post is my option 2.

[Corvince]

There are 2 options:

1. Move the Jupyter viz code to Mesa core. It's only 1 file after all
2. Publish mesa-models to PyPI

Sorry, but I am super annoyed right now at you @rht . I know you have a long tradition of misinterpreting my comments, but I cannot possibly understand how you can turn

Any objections with moving the Solara viz to core Mesa, @jackiekazil @Corvince ?

No objections from my side,

Into

@Corvince objects to option 1

Serious question, why are you doing this?

On the topic: I think we should go for option 1 and 2. I think it makes more sense to have the Viz stuff inside the main repo. For now I would recommend to put it under an experimental module. That is from mesa.experimental import JupyterViz instead of fron mesa.visualization import JupyterViz. This makes it more explicit that it is still rough around the edges.
But putting mesa-models on pypi is also something that should happen at some time.

[rht]

Just read your own comment: #1726 (comment).
Emphasis on

And thus communicate that it is not currently part of our public API and not subject to semver, since I think there will be quite some changes in the near future.

If that is not an objection, I don't know what it is.

[tpike3]

Let me try and summarize -

@Corvince
- option 1 now but with the caveat it is in mesa.experimental not mesa.visualization
- option 2 in the near future that mesa-models it is a library on PyPI

@rht
- is good with either 1 or 2; but 1 will require the tutorial to be updated

I like the option 1 now (no issues with the experimental caveat until we smooth the edges) and option 2 in the near future to make the models more accessible.

@jackiekazil let me know what you want do so we can get 2,0 out the door.

[jackiekazil]

@tpike3 ty for the summary... I had problems tracking.

I am good with 1 now then 2 in future... and that will solve the error that I am getting?

Let me know if there is anything I can do to help... review, etc

[arielolafsalgado]

Hello! Just to let you know I'm exploring the module. Today I noticed that the documentation says the jupyterViz is in mesa.visualization instead of experimental (still I found it thanks to this conversation).

Thanks a lot for your work!

[jackiekazil]

@arielolafsalgado - can you file a ticket so we can fix the error? We just recently moved it from experimental to the default and there are some artifacts we still need to update.