Opened 3 years ago

Closed 2 years ago

#21199 closed defect (wontfix)

do not relink python to python3

Reported by: dimpase Owned by:
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: packages: experimental Keywords:
Cc: jdemeyer, embray, chapoton Merged in:
Authors: Reviewers: John Palmieri
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

Installing optional package python3 currently breaks sage, as it relinks python to python3 in SAGE_LOCAL/bin. It should not do this.

See also this sage-devel thread.

Change History (25)

comment:1 Changed 3 years ago by dimpase

  • Cc jdemeyer embray added

comment:2 Changed 3 years ago by embray

  • Cc chapoton added

Agreed. Though I know work is also being done to make it possible to use python3 as the main Python for sage, in which case you would want to link python3 -> python. Is there some way when installing a Python in Sage to distinguish between it being installed as the "main" Python or as an optional package?

In the latter case then yes, it should not change the python link.

comment:3 Changed 3 years ago by leif

I've replied on sage-support...

(We should IMHO just make sure that Python3 -- just like GMP -- never gets installed when Sage is already built with the alternative, i.e., Python2 or MPIR. Changing the package currently requires rebuilding almost everything, i.e., from scratch.)

comment:4 Changed 3 years ago by leif

If having both Python2 and Python3 at the same time (modulo the link) really works (which I doubt), then we could of course just prevent symlinking local/bin/python to python{2,3} in the spkg-install files, in case the other Python is already installed.

comment:5 follow-up: Changed 3 years ago by dimpase

On Linux systems it's perfectly possible to have Pythons 2 and 3 alongside. On the other hand I must say I don't know in all details what the installation of python3 package may break in Sage.

comment:6 Changed 3 years ago by leif

Just for the record, we also have a symlink local/lib/python.


I bet people doing ./sage -i python3 will expect Sage to suddenly work with Python3, which is not the case. So I'd simply disable that option (for the time being).

I'm not entirely sure, but I think Cython extension modules compiled for/with Python2 won't work with Python3 (and vice versa), so we'd at least have to rebuild all of these.

Just having another Python interpreter inside Sage you cannot use with Sage IMHO doesn't make sense.

Last edited 3 years ago by leif (previous) (diff)

comment:7 in reply to: ↑ 5 Changed 3 years ago by leif

Replying to dimpase:

On Linux systems it's perfectly possible to have Pythons 2 and 3 alongside. On the other hand I must say I don't know in all details what the installation of python3 package may break in Sage.

There's update-alternatives (on Debian at least), but while you can otherwise of course have both python2 and python3 at the same time, you'd have to install any additional package into both, since these are separate, independent installations.

That's similar to having two instances of Sage, one configured to use Python2 (the default), the other with SAGE_PYTHON3=yes (IIRC).

comment:8 follow-up: Changed 3 years ago by embray

+1 there's no reason you shouldn't be able to have both simultaneously, and that would be especially good for development of Python 3 in Sage. Installing one just shouldn't break the other. Clearly that's not currently the case.

comment:9 in reply to: ↑ 8 ; follow-up: Changed 3 years ago by leif

Replying to embray:

+1 there's no reason you shouldn't be able to have both simultaneously

You mean in the same Sage installation?

Exactly that IMHO doesn't make sense, and would just cause lots of trouble (or needless additional work in order to support that, presumably just for a while anyway, since in the long run Sage will always and only build and use its own Python3).


and that would be especially good for development of Python 3 in Sage.

For developing migration, you should have a separate Sage installation configured with SAGE_PYTHON3=yes.


Installing one just shouldn't break the other. Clearly that's not currently the case.

Sure. Disable that, with an appropriate message if someone tries to... ;-)

comment:10 follow-up: Changed 3 years ago by dimpase

In fact, it turned out that to completely fix my Sage installation, I also needed to rebuild python2 package, and then run make. Otherwise ipython, doctesting, and some stuff related to dictionaries didn't quite work. So this is not that trivial, apparently, and needs further investigation.

comment:11 in reply to: ↑ 10 ; follow-up: Changed 3 years ago by leif

Replying to dimpase:

In fact, it turned out that to completely fix my Sage installation, I also needed to rebuild python2 package, and then run make. Otherwise ipython, doctesting, and some stuff related to dictionaries didn't quite work. So this is not that trivial, apparently, and needs further investigation.

I told you so... ;-)

comment:12 in reply to: ↑ 11 Changed 3 years ago by dimpase

Replying to leif:

Replying to dimpase:

In fact, it turned out that to completely fix my Sage installation, I also needed to rebuild python2 package, and then run make. Otherwise ipython, doctesting, and some stuff related to dictionaries didn't quite work. So this is not that trivial, apparently, and needs further investigation.

I told you so... ;-)

Well, this points out to more bugs, IMHO... On the other hand it could be the damage from setting the symbolic link the way it is done now, and if it did not happen then things work.

comment:13 Changed 3 years ago by leif

By the way, python3 doesn't even have an SPKG.txt, so it's not a valid spkg anyway. ;-)


W.r.t. having to reinstall python2:

The spkg-install files currently also wipe out $SAGE_LOCAL/lib/libpython* before installing the new version.

comment:14 follow-up: Changed 3 years ago by dimpase

no-no-no, SPKG.txt is obsolete...

comment:15 follow-up: Changed 3 years ago by leif

The by far easiest solution would be to change its type to experimental (which is pretty true at the moment), then the user would get prompted with a warning upon attempting to install it.

But we've just released 7.3...

comment:16 in reply to: ↑ 14 ; follow-up: Changed 3 years ago by leif

Replying to dimpase:

no-no-no, SPKG.txt is obsolete...

Nope:

$ ./sage --info python3
Found local metadata for python3-3.5.1
cat: .../build/pkgs/python3/SPKG.txt: No such file or directory
Last edited 3 years ago by leif (previous) (diff)

comment:17 in reply to: ↑ 16 Changed 3 years ago by dimpase

Replying to leif:

Replying to dimpase:

no-no-no, SPKG.txt is obsolete...

Nope:

$ ./sage --info python3
Found local metadata for python3-3.5.1
cat: .../build/pkgs/python3/SPKG.txt: No such file or directory

ah, OK, it's only the changelog part that is obsolete...

comment:18 in reply to: ↑ 9 Changed 3 years ago by embray

Replying to leif:

Replying to embray:

+1 there's no reason you shouldn't be able to have both simultaneously

You mean in the same Sage installation?

Exactly that IMHO doesn't make sense, and would just cause lots of trouble (or needless additional work in order to support that, presumably just for a while anyway, since in the long run Sage will always and only build and use its own Python3).

What do you mean exactly by "Sage installation"? You mean the filesystem in $SAGE_LOCAL? What's the big deal? I usually have like a dozen Pythons installed at the same time. This is no problem.

and that would be especially good for development of Python 3 in Sage.

For developing migration, you should have a separate Sage installation configured with SAGE_PYTHON3=yes.

That's a lot of duplicated software just to have two different Pythons installed. No, that doesn't make any sense. Currently you may have to do that--I'm just saying ./sage itself should know which Python it's using, and be able to switch that as needed.

comment:19 in reply to: ↑ 15 Changed 3 years ago by mkoeppe

Replying to leif:

The by far easiest solution would be to change its type to experimental (which is pretty true at the moment), then the user would get prompted with a warning upon attempting to install it.

But we've just released 7.3...

Changing it to experimental is now #21698. Please let's get this into 7.4.

comment:20 Changed 3 years ago by mkoeppe

  • Component changed from packages: optional to packages: experimental
  • Milestone set to sage-7.6
  • Priority changed from critical to major

comment:21 Changed 3 years ago by vbraun

  • Milestone changed from sage-7.6 to sage-duplicate/invalid/wontfix

This is implemented in #22582, proposing to close as duplicate

comment:22 Changed 3 years ago by jhpalmieri

  • Status changed from new to needs_review

comment:23 Changed 3 years ago by jhpalmieri

  • Reviewers set to John Pamieri
  • Status changed from needs_review to positive_review

I'm not sure I agree that we should not link python to python3 some of the time, but we can resolve it at #22582. A lot of the discussion here is not directly relevant anymore, since python3 is now standard.

comment:24 Changed 3 years ago by jhpalmieri

  • Reviewers changed from John Pamieri to John Palmieri

comment:25 Changed 2 years ago by embray

  • Resolution set to wontfix
  • Status changed from positive_review to closed

Closing tickets in the sage-duplicate/invalid/wontfix module with positive_review (i.e. someone has confirmed they should be closed).

Note: See TracTickets for help on using tickets.