Proposal discussion for Cantor: Python 3 as the only backend officially supported
alexander.semke at web.de
Mon Jan 8 22:25:15 UTC 2018
> Yesterday I wrote a post in my blog about a proposal to Cantor.
> Currently, Cantor has 11 backends but most of them are not maintained.
> The consequence is several backends are broken or not working as
> expected. I waste a lot of time trying to fix backends I don't use, and
> I don't have time to work in new features for Cantor itself.
> My proposal is officially maintain only Python 3 backend, move the other
> backends to a community/third-party repository and, if someone cares
> about them, release some of them as extensions in KDE Store.
Nobody, well, except of you, cares about them at the moment. Why should
this change if you move this code to KDE store?
> This way I can work better with Cantor.
> Just to say, I tried in past solve it inviting developers to be
> co-maintainers of the backends, but it does not work as I expected.
This is understandable. At least for big players like python and julia
that have Jupyter, R that has R-Studio, Sage that has cocalc.com and
Octave and scilab with their own frontends. Why should the developers
from these communities care about Cantor?
To attract more developers we need to improve Cantor greatly first and
to provide some benefits and advantages compared to other solutions. I
know, this is kind of a hen egg problem, but still..
Which backends are causing the most problems at the moment? Is it Sage?
More information about the kde-edu