feat: support python 3.6

[railway-app[bot]]

This PR is being deployed to Railway 🚅

web: ◻️ REMOVED

[maartenbreddels]

Windows and Python 3.6 seems to be difficult to support, so we'll skip that for now.

[EwoutH]

If I may ask, why add the Python 3.6 support? It seems like it complicates the code based and especially dependency management and (CI) testing. The Python 3.6 end-of-life date was 2021-12-23, so support for it was added after its end-of-life date.

[maartenbreddels]

Hi @EwoutH ,

Good question! End-of-life does not mean that it is not being used anymore. We encountered instances of users or environments at large enterprises that, for various reasons, could not upgrade. We don't want to alienate these users. Also, I don't think the burden is very high, as you can see, there are not many changes needed. Does that make sense?

Regards,

Maarten

[EwoutH]

@maartenbreddels Yes, thanks for getting back!

Is there demand for "a Solara version that just works" on Python 3.6, or are they actually wanting new (feature) releases? Or otherwise: Is there a big intersection of users both still on Python 3.6 and requiring new Solara features/bugfixes? I'm trying to gauge the overlap of users who are still on Python 3.6 and those who are anticipating new features or bug fixes in Solara.

If the demand isn't high, one approach could be to consider phasing out support for Python 3.6 and 3.7 in future Solara releases, especially since both versions are now end-of-life. This would free up maintenance capacity, allow usage of newer Python features and reduce complexity in dependency management.

For example, in the pyproject.toml there are quite some packages that need a special rule for Python 3.6. That means different version of packages are used for different Python versions, which again means that those combinations need to be tested and maintained.

Today I went trough the codebase (we might be picking up Solara as main visualisation method in Mesa), and to be honest, it seems like Solara could use a bit of maintenance. I opened some PRs (#344, #346, #347, #348 and #350) and an issue (#349) that hopefully help a bit, most come down to consistent maintenance of infrastructure and testing policies. Ideally those would be updated at a regular interval (monthly or quarterly, or before each release), but some haven't been touched for over a year.

If there is enough (maintenance, testing and CI) capacity to support everything, that would be ideal. But if not, it might be worth considering supporting current, not end-of-life, Python versions (like 3.10, 3.11, 3.12) at least to the same extend as the older ones.

Anyway, I hope that I could offer some insights on the other side of the coin, in the end you as maintainers have the best picture of priorities. I hope that the PRs and issue help a little bit and happy do discuss each of them there!

[maartenbreddels]

This would free up maintenance capacity

I don't really see that. If we do hit this problem, we can always do that, but if it doesn't cost us time/effort/money I prefer not to pro-actively remove it.

If there is enough (maintenance, testing and CI) capacity to support everything, that would be ideal. But if not, it might be worth considering supporting current, not end-of-life, Python versions (like 3.10, 3.11, 3.12) at least to the same extend as the older ones.

Most downloads are 3.9 now, and I really do not want to stop supporting that right now.

We see a different set of users (at large enterprises) that cannot run modern Python versions and still run those. Note that end-of-live does not mean that it is unsafe to run. In airgapped environments there are less security concerns for instance. Also, I believe support can be bought from 3rd parties.

I respect sharing your thought, but it is actually a mindset that we actively push again :)

If supporting 3.6 would really hurt us, I'm okay with dropping it!