Preparing for the long overdue 1.1 release

[GarkGarcia]

I think the work we've been putting recently on fixing major issues deserves a (long overdue) release, but there are some things we need to address before releasing the next version:

1. We need to contact @sn6uv to ask him to transfer the ownership of the PyPI entry for Mathics to some active contributor, so that we can release the updates in PyPI.

2. We need to complete the 1.1 Milestone.

I've recently updated the milestone to include some issues that I thought should be addressed before the release. @wolfv @mmatera @poke1024 @suhr @rocky and other active contributors, please feel free to include any additional issues and PRs to the milestone.

[suhr]

I want to create a NixOS package. I don't need a PyPI release for this, but I need a git tag. So it may make sense to release 1.1 on github before releasing it to PyPI.

[GarkGarcia]

I want to create a NixOS package. I don't need a PyPI release for this, but I need a git tag. So it may make sense to release 1.1 on github before releasing it to PyPI.

That would be a great addition. We should probably create .deb and arch packages too, even if don't submit them to the official package repositories. I'll create an issue to address this.

However, I think this could be addressed after the release. We've already got quite a lot things to fix for the next two months 😅️

[rocky]

@suhr Can't you create a package off of a git sha?

The problem with creating a tag and then coming up with a PyPI package is that things can be discovered just in the packaging. And there is a tempation to add features that have been added since the tag. So from a package repo's standpoint, e.g. PyPI, it seems silly to have a 1.0 version, then a 1.2 version without a 1.1 version.

[suhr]

Can't you create a package off of a git sha?

I can, but this is awkward and also not suitable for nixpkgs.

[GarkGarcia]

@rocky @suhr @wolfv @mmatera @poke1024 We could divide the remaining issue among ourselves.

Also, I'm considering removing #635 from the milestone. Graphics seems to be the most common source of bugs and I'm not sure we'll be able to address it properly in the time-frame we have.

The time-frame I set for the milestone is completely arbitrary (so extending it is a possibility), but I got a sense of urgency on regards to releasing the recent changes. It's been 4+ years since the last update.

[rocky]

I just started a new job and need to focus on that. I really can't commit to any time reliably. I will go over the docs, doc making code and the makefile stuff since that I can do without much thought.

The things I am personally interested in is being able to show the translation InputForm to FullForm (which is there already but just hidden from the user), and fixing the various bugs and deficiencies in parsing the language I think I have noticed. I would also like to have a Mathematica to Python translator out of this like I currently do with FoxySheep2 on a much more primative level.

The approach would be a taking Mathematica input dumping the Python AST as Python source code which can be run from Python.

From there you can modify the Python however you like. Of course the Python would largely be making calls to mathics modules as happens now.

Possibly out of this, I could produce tables of equivalents constructs. I've been thinking of doing this on the FoxySheep2 code as well.

None of this though is part of a milestone and should not be in that. I'll also probalby tweak simple stuff or whatever bothers me when I use mathics.

Locally I have added Environtment, and started SetEnvironment and GetEnvironment. But this kind of stuff to shouldn't be part of a milestone

[wolfv]

Regarding ast work I recommend the gast package to have a python version independent ast

[rocky]

Regarding ast work I recommend the gast package to have a python version independent ast

Interesting. The presumption is that with this then the recent changes where we had to test the python version for 3.8+ ness or posonlyargs would have been handled if we had converted to gast and then converted out of that just before the compile.

Will look into that in the future. However to set expectations, I expect a more major upheaval to the whole AST process to try to preserve location information when doing transformations. So already I was thinking rebasing _ConditionalTransfrormer to subclass off of something other than ast.NodeTransformer which will preserve information that is copied from one ast to the new one. So in that I could use gast.

I should note though that because this is major upheaval, I wouln't expect it to be in the next release which is largely a bug fix, update to more recent-releases of software, and clear-out-the backlog release.

[suhr]

It finds out, NixOS has no django_1_11 anymore. So we probably should really switch to django 2.2.

[rocky]

How much work is that? Roughly what are the differences?

[rocky]

Answering my own question: https://stackoverflow.com/questions/55798286/django-1-1-vs-django-2-2