Preparing for the long overdue 1.1 release #841
Comments
|
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 😅️ |
|
@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. |
I can, but this is awkward and also not suitable for nixpkgs. |
|
@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. |
|
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 |
|
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 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 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. |
|
It finds out, NixOS has no django_1_11 anymore. So we probably should really switch to django 2.2. |
|
How much work is that? Roughly what are the differences? |
|
Answering my own question: https://stackoverflow.com/questions/55798286/django-1-1-vs-django-2-2 |
I agree. I think we should focus on updating our dependencies and fixing major issues, instead of trying to address small bugs. |
To be clear, I'm not implying there are contributors who only address small bugs or anything like that. I've been thinking a lot about what is our best course of action is, and as of now this are the issues I think we should focus on (in order):
|
I'm my opinion, we should focus in the first two items for the next release. |
|
@GarkGarcia @rocky @wolfv @suhr @sn6uv @poke1024 @poeschko
#888 and #843 are what I have in mind we need to address now. Any other urgent thing? |
|
For #888 I have done a minimal conversion locally. However I think we should pull it - I am not going to have the time it needs. And at best it wasn't very good in my opinion. When put through paces via Combinatorica showed that clearly; focusing on better networkx integration will do a much better job. As for #843 this is somewhat administrative and a bit vague. Whatever is easy can be done, but I wouldn't sweat this outside of PyPI whch I could do very easily. I suspect docker is easy to to do as well, so okay. For the others I don't see why this isn't as good after a release. Why delay a release working on say problems with Debian? Package managers already are well versed with how to fix things up after a release and package managers work fine using patches. And those patches then go into the next release, so there's no loss. For something this long between releases and with so muh in it, plan on a minor release to catch little things. I was thinking of this as 1.1.1 not 1.2 or 2.0 |
|
@mmatera One little thing I would like to see for the next release is handling The motivation here is to start allow people to pull down and try Mathematica code from the Internet in Mathics. It doesn't seem like this would be a lot of work. Little things like this help (and in my opinion SansSerif is in that category). The worry about introducing bugs, is more about adding larger stuff, not the smaller stuff. (The irony here and why I haven't looked at this or tried it has to do with the brokenness of master, not this). The conventional way of handling worry about user interface bugs slipping in (aside from beefing up tests) is to have a lock-down period before release where we try things and ask folks to do likewise. |
<<"http://www2.fisica.unlp.edu.ar/~matera/test.m" or The other syntax would require modifying the behavior of the @ operator... |
|
Great! This is good to know. For 1.1 in my opinion this is good enough - was just hoping there was a way to do it. Making it compatible with Mathematica can come later. (And perhaps this is already compatible) |
|
Actually, Import @ modulepath would import the package as a text file. If you want that it loads modulepath as a package, we just need to define a handler in the autoloads/export folder |
|
If this is simple to do, please do it. |
I created the 1.1 milestone for that purpose. If you'd like to have an issue addressed before the release feel free to add it to the milestone.
I agree. It's better for us to not release Graphs, given our time-frame.
I agree too, this doesn't need to be addressed before the release. We could work on that after we release the code in PyPI. |
|
@rocky Were you able to post a note about the release candidate in the Google Groups forums and in Slack channel? |
|
I'll contact @poeschko via email in about a week or so for us to publish the release in PyPI (if he doesn't see the discussion in here before that). |
|
I'll post something Wednesday evening. |
Great! |
|
Announcements have now been sent to
- @here on the #general mathics slack channel
- the mathics-users google group
- the sage-devel google group
I am okay if we hook up Friday 10 minutes early. Suggest a way to do so.
…On Wed, Oct 28, 2020 at 5:34 PM Gark Garcia ***@***.***> wrote:
I'll post something Wednesday evening.
Great!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#841 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAACFE3SLX2GUIAOYVHMDETSNCE5ZANCNFSM4Q755GWQ>
.
|
Awesome! Thanks for that!
My idea was for us to join the meeting 10 minutes before the presentation start. I'm now thinking this may not be necessary at all. |
|
Better would be to do a practice run of the talk for timing.
…On Thu, Oct 29, 2020 at 5:37 AM Gark Garcia ***@***.***> wrote:
Announcements have now been sent to
- @here <https://github.com/here> on the #general mathics slack channel
- the mathics-users google group
- the sage-devel google group
Awesome! Thanks for that!
I am okay if we hook up Friday 10 minutes early. Suggest a way to do so.
My idea was for us to join the meeting 10 minutes before the presentation
start. I'm now thinking this may not be necessary at all.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#841 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAACFEZWMKHGSMXJ4IFWW4DSNEZWBANCNFSM4Q755GWQ>
.
|
Sure, I'm available today or tomorrow before the presentation. |
|
The only time I will have free will be about 1 hour before demo time which should be 3PM brazil time and 2PM NYC time, right? Since the whole thing is 20 minutes though this should be enough time to go over. |
Sure, we can meet at 3PM (UTC-3) in https://bbb.imo.universite-paris-saclay.fr/b/jul-sim-7a6-zuk. |
|
@rocky It looks like we can't join that meeting yet since it hasn't been started. I'm creating another meeting for us to use tomorrow. |
|
Here's a link to the room I created: https://demo.bigbluebutton.org/gl/pab-53l-heb-aq8 |
|
@mmatera and @GarkGarcia I revised the demo. The changes were
Went over the tree heirarchy. In that process I removed the slide that had the sole text "What is Mathics". Added a subslide on Diversity. Since that is a down-arrow thing that can be skipped. I can talk about that too if it is confusing. Please look over this material and the slide view. Thanks. |
|
Looks good. Still has a few typos, but I can fix them tomorrow morning. |
|
@GarkGarcia @mmatera Can't get in to https://demo.bigbluebutton.org/gl/pab-53l-heb-aq8 How about https://meet.jit.si/Mathics1.1milestone |
|
I miss the connection. I do not know when... :( |
|
For some reason, the connection interrupts all the time. Sorry... |
|
I can't do over this upcoming weekend, but the next one is probably fine to do. Here are my thoughts about this. There really hasn't been much feedback on the 1.1.0 preview so I'll take that as good news. Since 1.1.0 preview except for separating the Django frontend which just started, I'd say that all of the other changes have been more or less incremental improvements. I'd even say that the PyMathics stuff was really all mostly there and I just had a chance to make another spurt to get it further. (natlang and mathicsscript are okay to release afterwards on PyPI as Pymathics modules that depend on Mathics. graphs "works" in terms of loading, but is just as crappy as it was before, maybe even worse since when I tried it last I couldn't get any graphics to come out because I was running into recursion errors.) So given the above:
I think the 1.1.0 release should include the improvements since the preview release. I am not sure about separating Django into its own package. Since doing PyPI release will introduce a little more stuff, I'd like to do that on my own just this last time. So let's say we do 1.1.0 without Django separated, and then shortly after that 1.2.0 with Django detached and Gark (and others who want to watch) and I doing the release. (Gark or someone else can drive, and I'll just watch. @GarkGarcia @mmatera thoughts? Oh, and I assume Mathics3 is an okay name for Mathics for Python 3+? |
That could also mean there isn't many people using Mathics at the moment, but I agree with you.
I agree.
I intended to merge this after 1.1. There's still a lot more work for us to do before merging. We need to update the documentation and we need to create a repository for the web interface.
I should probably refactor
Sounds good to me.
Sure. |
As someone who has been doing this open-source stuff for a while, I think you just have to take a long view of such things. And what can happen (or has to me), is that at some point some event will happen, like it getting included in a well-known project or put in a well-known distribution (unknown to you), and then all of a sudden this sleepy little project you've been working on becomes a big deal. The way you find out is just because one day there are dozens of new issues reported.
Good to hear.
Yes, the problems that I am most keenly aware of are graphics related. And were these solved, I think we'd see a huge boost in quality of graphics for Django as well. Better axis labelling and way more graphics options available. |
|
I agree with you both that at least 1.1 release should keep django and the current command line interfaces. What we could do is to start building the projects for the django interface, as @rocky has done with mathicsscript. Something else I would like to have ready before splitting the interface from the kernel is a better interface with Python library, with something like a "MathicsSession" object, instead of the current way calling internals. In this way, someone who is just insterested in the kernel does not need to download all the package. |
|
1.1. has long come and gone. |
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:
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.
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.
The text was updated successfully, but these errors were encountered: