Le 10/01/2020 à 14:54, E. Madison Bray a écrit :
On Fri, Jan 10, 2020 at 11:49 AM Isuru Fernando <[email protected]> wrote:
On Fri, Jan 10, 2020 at 3:53 PM E. Madison Bray <[email protected]> wrote:
On Fri, Jan 10, 2020 at 10:41 AM Timo Kaufmann <[email protected]> wrote:
I have said this before, but I feel like the point was dropped out of the discussion so
I'll stress it again. The major issue here is *not* the compatibility of sage's own
codebase. A few "from __future__ import"'s are not so bad.
The issue is that python2 compatibility forces us to use outdated versions of a
lot of libraries, since many libraries have dropped python2 support a while
ago. This is a big headache especially for packagers. Those outdated libraries
are generally not available on distros. At the same time sage is usually not
compatible with the newer versions. Sage is already difficult to package, and
that makes it a lot more difficult.
Can you be more specific about this? What is it about Sage's upstream
codebase maintaining backwards-compatibility for Python 2 that
prevents you from packaging it for Python 3 only, given that it does
support Python 3? No one is saying that just because upstream support
is maintained for Python 2 for one or two (at the most) more releases,
any downstream packagers have to package it for Python 2.
I'll give an example. sage has rpy2 2.8.2.
rpy2 latest is 3.2.4 but 3.x series is python 3 only and sage requires breaking
changes to support rpy2 3.x. See
https://trac.sagemath.org/ticket/28494#comment:6
While python2 support for rpy2 is required, sage codebase can't be updated to
3.x (unless someone adds code to detect rpy2 version and support both 2.8.2 and
3.2.4)
That seems like the obvious approach to me. As it is I've long felt
that Sage should be more flexible in its dependencies where
possible/necessary. With most Python packages it's easy as most have
a <package>.__version__ and its not so hard to define some variable
like IS_RPY_2 and just have two separate branches. I have things like
that all over the place in other packages to support e.g. different
Numpy versions or work around version-specific bugs.
+1. I also do that with many Python packages that I develop and depend
on Sage. This is the only way I found to support multiple Sage versions.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/5f87ae84-023d-4cbf-e8fc-75f894ee543a%40gmail.com.
