python3 status

[Frédéric Chapoton]

Hello,

here is a small report on the slow progress towards python3-compatibility for sage.

Sage is already building and starting with python3 since some time already. It is explained in https://trac.sagemath.org/ticket/15530 how to get a python3-sage. One can note an even longer startup time (sigh).

There has been recent progress on the pexpect interfaces and lib interfaces, so this sage3 is now somewhat usable. Try it !

Our next goal is to get the documentation build. After that, one will have to make all doctest pass, but we are still a long way from that.

Another interesting step would be to be able to launch the jupyter notebook with sage3. Currently, it looks for the sage kernel in the python2 library (no ticket yet).

The current result of trying to build the doc can be seen here : 

https://patchbot.sagemath.org/log/0/Ubuntu/18.04/x86_64/4.15.0-20-generic/petitbonum/2018-05-27%2021:55:21?plugin=docbuild

Apparently, we are not so far to manage building the documentation. Two important issues, responsible for many errors in docbuilding:

(A) fix some heavy problem of hash in the manifolds code, see https://trac.sagemath.org/ticket/25393

(B) need to reactivate the build of sagenb in python3 : see https://trac.sagemath.org/ticket/22431

Ticket 22431 above need people to check (1) that the upgraded sagenb works smoothly on python2 and (2) that sage3 still builds and starts after building sagenb.

(note that even after 22341, sagenb will not work in sage3, due to some missing parts of twisted, that require upgrading twisted.)

Does somebody care ?

Frédéric

[Nils Bruin]

On Tuesday, May 29, 2018 at 8:59:27 AM UTC-7, Frédéric Chapoton wrote:

Hello,

here is a small report on the slow progress towards python3-compatibility for sage.

Sage is already building and starting with python3 since some time already. It is explained in https://trac.sagemath.org/ticket/15530 how to get a python3-sage. One can note an even longer startup time (sigh).

There has been recent progress on the pexpect interfaces and lib interfaces, so this sage3 is now somewhat usable. Try it !

Congratulations and thank you for the hard work on something that is ultimately absolutely required.
 

Our next goal is to get the documentation build. After that, one will have to make all doctest pass, but we are still a long way from that.

Another interesting step would be to be able to launch the jupyter notebook with sage3. Currently, it looks for the sage kernel in the python2 library (no ticket yet).

That's sage.repl.ipython_kernel.SageKernelSpec._kernel_cmd, which currently invokes "$SAGE_LOCAL/bin/sage --python". If you change that to "--python3" it should be OK. I guess we can have two kernel specs: sage/Py3 and sage/Py3. [on a different note, it would also be useful to use a "sage" executable that can figure out $SAGE_ROOT from scratch. Then the kernelspec is usable with arbitrary jupyters]

[Samuel Lelievre]

Tue 2018-05-29 15:59:27 UTC, Frédéric Chapoton:

>

> here is a small report on the slow progress towards Python3-compatibility

> for Sage.

>

> Sage is already building and starting with python3 since some time already.

> It is explained in https://trac.sagemath.org/ticket/15530 how to get

> a python3-sage. One can note an even longer startup time (sigh).

>

> There has been recent progress on the pexpect interfaces and lib interfaces,

> so this sage3 is now somewhat usable. Try it !

Hi Frédéric, thanks for the hard work on making Sage Python3-compatible!

I succeeded in building Sage 8.3.beta1 both for Python2 and for Python3.

I started using "SagePy3" for regular work, switching to "SagePy2" only

when "SagePy3" won't do the work. I thus noted there's a fair amount one

can already do with "SagePy3".

> Our next goal is to get the documentation build. After that, one will have

> to make all doctest pass, but we are still a long way from that.

> Another interesting step would be to be able to launch the jupyter notebook

> with sage3. Currently, it looks for the sage kernel in the python2 library

> (no ticket yet).

>

> The current result of trying to build the doc can be seen here: 

>

> https://patchbot.sagemath.org/log/0/Ubuntu/18.04/x86_64/4.15.0-20-generic/petitbonum/2018-05-27%2021:55:21?plugin=docbuild

>

> Apparently, we are not so far to manage building the documentation. Two

> important issues, responsible for many errors in docbuilding:

>

> (A) fix some heavy problem of hash in the manifolds code, see

> https://trac.sagemath.org/ticket/25393

>

> (B) need to reactivate the build of sagenb in python3, see

> https://trac.sagemath.org/ticket/22431

>

> Ticket 22431 above need people to check (1) that the upgraded sagenb

> works smoothly on python2 and (2) that sage3 still builds and starts

> after building sagenb.

>

> (note that even after 22341, sagenb will not work in sage3, due to some

> missing parts of twisted, that require upgrading twisted.)

>

> Does somebody care ?

I care a lot! But all I can do so far (not that it helps a lot) is build

each new beta both for Py3 and Py2 and work primarily with the Py3 one,

switching to the Py2 one only as needed.

By the way, did "SagePy3" 8.3.beta2 build for anyone? I had no luck getting

it to build under (now unsupported) macOS 10.10.5. I have to try 8.3.beta3

now that it is out.

Do we ensure each new beta builds for Py3 on supported platforms?

Maybe the announcement for each new beta on sage-release could remind

readers that https://trac.sagemath.org/ticket/15530 has the instructions

for building a Python3-based Sage?

[Jeroen Demeyer]

On 2018-05-29 22:57, Nils Bruin wrote:
> it would also be useful to
> use a "sage" executable that can figure out $SAGE_ROOT from scratch.

Can you say more precisely what you mean with this?

[Nils Bruin]

Currently, if I run the script $SAGE_LOCAL/bin/sage in my normal environment (where SAGE_ROOT is not set) then I get:

Error: You must set the SAGE_ROOT environment variable or run this
script from the SAGE_ROOT or SAGE_ROOT/local/bin/ directory.
Error setting environment variables by sourcing '/usr/local/sage/sage-git/local/bin/sage-env';
possibly contact sage-devel (see http://groups.google.com/group/sage-devel).

If instead I run the script $SAGE_ROOT/sage a value for SAGE_ROOT is figured out and everything works fine when called from my normal environment.

If I change sage's kernel_spec to run the latter, I can use the whole SAGE_LOCAL/share/jupyter/kernels/sagemath jupyter kernel description directly with /usr/bin/jupyter (via a symlink or so).

I think that's an advantage. If it were up to me, I would probably inject the logic of SAGE_ROOT/sage into SAGE_LOCAL/bin/sage because for me that would work fine.

Linking to SAGE_LOCAL/share/jupyter/kernels/sagemath has the advantage that upgrades are automatically picked up when I use /usr/bin/jupyter. I can of course copy & edit files, but then they are not kept up-to-date.

Similarly, I could edit the file in-place (e.g., equip the script with a hard-coded value for SAGE_ROOT), but then I have to deal with a source tree that is forever patched wrt. vanilla.

[Matthias Koeppe]

On Wednesday, May 30, 2018 at 9:01:59 AM UTC-7, Nils Bruin wrote:

Currently, if I run the script $SAGE_LOCAL/bin/sage in my normal environment (where SAGE_ROOT is not set) then I get:

Error: You must set the SAGE_ROOT environment variable or run this
script from the SAGE_ROOT or SAGE_ROOT/local/bin/ directory.
Error setting environment variables by sourcing '/usr/local/sage/sage-git/local/bin/sage-env';
possibly contact sage-devel (see http://groups.google.com/group/sage-devel).

If instead I run the script $SAGE_ROOT/sage a value for SAGE_ROOT is figured out and everything works fine when called from my normal environment.

I agree that we should make $SAGE_LOCAL/bin/sage work without environment variables set.

We discussed this in https://trac.sagemath.org/ticket/21479 ("./configure --prefix=SAGE_LOCAL"), when $SAGE_LOCAL/bin/sage-env-config was introduced; but then a less ambitious solution was implemented for that ticket.

We could add a line setting $SAGE_ROOT in $SAGE_LOCAL/bin/sage-env-config (via src/bin/sage-env-config.in).

On the other hand, of course, most uses of SAGE_ROOT have been eliminated (see https://trac.sagemath.org/ticket/21591 - Replace use of SAGE_ROOT by more specific environment variables); and it would be good to finish this job and allow sage to work without having to complain about this environment variable.

[Emmanuel Charpentier]

I'm grabbing the opportunity to recall that , whereas I have installed the Sage kernel in my (systemwide) jupyter installation via the suitable "jupyter kernelspec install ..." invocation), when I try to use it from the systemwide jupyter via the "normal" invocation "jupyter notebook", it complains of SAGE_ROOT being undefined and does not lauch Sage. OTOH, if  I invoke "SAGE_ROOT=<whatever> jupyter notebook", all is fine and dandy. My $SAGE_ROOT/sage script is symlinked to /usr/local/bin/, which is on my $PATH.

Suggestions ?

--

Emmanuel Charpentier

[Nils Bruin]

On Thursday, May 31, 2018 at 4:52:04 AM UTC-7, Emmanuel Charpentier wrote:

I'm grabbing the opportunity to recall that , whereas I have installed the Sage kernel in my (systemwide) jupyter installation via the suitable "jupyter kernelspec install ..." invocation), when I try to use it from the systemwide jupyter via the "normal" invocation "jupyter notebook", it complains of SAGE_ROOT being undefined and does not lauch Sage. OTOH, if  I invoke "SAGE_ROOT=<whatever> jupyter notebook", all is fine and dandy. My $SAGE_ROOT/sage script is symlinked to /usr/local/bin/, which is on my $PATH.

Suggestions ?

 

Yes, that is very close to my usage scenario as well (as an aside: "jupyter kernelspec install" on the sage kernel involved COPYING all the sage documentation into the kernelspec directory. In most scenarios symlinking it is more appropriate (that's how sage installs its kernel in its own kernel)

If you are placing your kernel.json outside of the sage installation anyway, you can edit the relevant "kernel.json" to refer to "sage" rather than the hard path to $SAGE_LOCAL/bin/sage that is there presently. The changes we are discussing here would avoid having to make that edit.

[Matthias Koeppe]

I have created https://trac.sagemath.org/ticket/25486 for this.

[Emmanuel Charpentier]

Dear Nils,

Le jeudi 31 mai 2018 18:31:31 UTC+2, Nils Bruin a écrit :

On Thursday, May 31, 2018 at 4:52:04 AM UTC-7, Emmanuel Charpentier wrote:

I'm grabbing the opportunity to recall that , whereas I have installed the Sage kernel in my (systemwide) jupyter installation via the suitable "jupyter kernelspec install ..." invocation), when I try to use it from the systemwide jupyter via the "normal" invocation "jupyter notebook", it complains of SAGE_ROOT being undefined and does not lauch Sage. OTOH, if  I invoke "SAGE_ROOT=<whatever> jupyter notebook", all is fine and dandy. My $SAGE_ROOT/sage script is symlinked to /usr/local/bin/, which is on my $PATH.

Suggestions ?

 

Yes, that is very close to my usage scenario as well (as an aside: "jupyter kernelspec install" on the sage kernel involved COPYING all the sage documentation into the kernelspec directory. In most scenarios symlinking it is more appropriate (that's how sage installs its kernel in its own kernel)

Should I revert to symlinking ? It seems not :

 

If you are placing your kernel.json outside of the sage installation anyway, you can edit the relevant "kernel.json" to refer to "sage" rather than the hard path to $SAGE_LOCAL/bin/sage that is there presently. The changes we are discussing here would avoid having to make that edit.

  So, at least for now, I'd better *copy* kernel.json (to be able to edit) and symlink the rest (incl. documentation). And the patch under discussion should allow for simple "standard" installation. Right ?

--

Emmanuel Charpentier