Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)
Le 10/01/2019 à 22:03, Jeroen Demeyer a écrit : On 2019-01-10 21:51, 'Julien Puydt' via sage-devel wrote: Didn't François mention changing SAGE_ROOT wasn't needed? He said SAGE_ROOT should only be needed for the packaging system and possibly the doctests. I regard any needs for SAGE_ROOT at runtime a bug. In other words: it is still needed, but that's a bug. And I agree with that. https://trac.sagemath.org/ticket/27040 JP -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)
> On 11/01/2019, at 09:48, Jeroen Demeyer wrote:
>
> On 2019-01-10 20:46, 'Julien Puydt' via sage-devel wrote:
>>
>>
>> Le 10/01/2019 à 20:07, François Bissey a écrit :
>>> I have recently made the following change in sage-on-gentoo’s env.py
>>> _add_variable_or_fallback('SAGE_LOCAL',
>>> sysconfig.get_config_var("prefix”))
>>>
>>> which means SAGE_LOCAL is now pulled from the system rather than
>>> a seeded value (as it was before).
>>>
>>
>> Perhaps upstream would accept such a trivial change?
>
> If you make a ticket for it, sure. But it won't help with SAGE_ROOT.
>
> By the way, why sysconfig.get_config_var("prefix”) instead of sys.prefix?
Because at least on gentoo sys.prefix (while correct) is a bit weird. It is
defined
relative to the real python executable which ends up being a strange location on
Gentoo due to the system to support multiple python.
/usr/lib/python-exec/python{2.7,3.6}/../../..
This is the right place but a bit confusing, sysconfig on the other hand always
return
something clearly understandable. There is another reason, SAGE_LOCAL is not
the
only thing I set using sysconfig
SINGULAR_SO = sysconfig.get_config_var("LIBDIR")+"/libSingular.”+extension
I used to have all those weird mechanism to deal with lib/lib64 (and who knows
what
is needed in debian). But really I have nothing against sys.prefix.
SAGE_ROOT is not needed at runtime for distros but it is definitely not the same
thing for “vanilla” as things stands. Since vanilla still insists on integration
with the build system and completely removing it, is hard in some parts.
Also it is quite deliberately set to None (and SAGE_LOCAL too) in vanilla -
probably
so you can’t run sage outside of a sage set environment.
François
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)
On 2019-01-10 21:51, 'Julien Puydt' via sage-devel wrote: Didn't François mention changing SAGE_ROOT wasn't needed? He said SAGE_ROOT should only be needed for the packaging system and possibly the doctests. I regard any needs for SAGE_ROOT at runtime a bug. In other words: it is still needed, but that's a bug. And I agree with that. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)
Hi, Le 10/01/2019 à 21:48, Jeroen Demeyer a écrit : On 2019-01-10 20:46, 'Julien Puydt' via sage-devel wrote: Perhaps upstream would accept such a trivial change? If you make a ticket for it, sure. But it won't help with SAGE_ROOT. Didn't François mention changing SAGE_ROOT wasn't needed? JP -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)
On 2019-01-10 20:46, 'Julien Puydt' via sage-devel wrote:
Le 10/01/2019 à 20:07, François Bissey a écrit :
I have recently made the following change in sage-on-gentoo’s env.py
_add_variable_or_fallback('SAGE_LOCAL', sysconfig.get_config_var("prefix”))
which means SAGE_LOCAL is now pulled from the system rather than
a seeded value (as it was before).
Perhaps upstream would accept such a trivial change?
If you make a ticket for it, sure. But it won't help with SAGE_ROOT.
By the way, why sysconfig.get_config_var("prefix”) instead of sys.prefix?
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)
Le 10/01/2019 à 20:07, François Bissey a écrit :
I have recently made the following change in sage-on-gentoo’s env.py
_add_variable_or_fallback('SAGE_LOCAL', sysconfig.get_config_var("prefix”))
which means SAGE_LOCAL is now pulled from the system rather than
a seeded value (as it was before).
Perhaps upstream would accept such a trivial change?
JP
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)
> On 11/01/2019, at 05:04, E. Madison Bray wrote:
>
> If you want to look-before-you-leap you could also check if
> `SAGE_ROOT` and `SAGE_LOCAL` are set to something reasonable in
> `os.environ`.
Just SAGE_LOCAL. SAGE_ROOT should only be needed for the packaging system
and possibly the doctests. I regard any needs for SAGE_ROOT at runtime
a bug.
> I have mentioned elsewhere (e.g. on
> https://trac.sagemath.org/ticket/22652) that the sage.env module ought
> to be fixed upstream (that is, in the main Sage sources) so that it
> can actually work properly without having to set any special
> environment variables.
I have recently made the following change in sage-on-gentoo’s env.py
_add_variable_or_fallback('SAGE_LOCAL', sysconfig.get_config_var("prefix”))
which means SAGE_LOCAL is now pulled from the system rather than
a seeded value (as it was before).
François
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)
On Thursday, January 10, 2019 at 9:58:56 AM UTC-6, E. Madison Bray wrote:
>
> > On archlinux that also uses system Python for Sage the
> > situation is better: importing sage.all in Python2 does work! Even
> > though the configuration constants are not in the environment! They
> > are set up properly in sage_env.py that is part of the SageMath
> > installation. And more precisely $SAGE_LOCAL fallsback to the default
> > "/usr" which is what it is intend to be on archlinux.
> >
> > I don't understand why on Debian $SAGE_LOCAL is set to None and
> > managed by environment variables.
>
> I have mentioned elsewhere (e.g. on
> https://trac.sagemath.org/ticket/22652) that the sage.env module ought
> to be fixed upstream (that is, in the main Sage sources) so that it
> can actually work properly without having to set any special
> environment variables. Even if it has to guess in some cases, and has
> to raise a RuntimeError if it can't reasonably guess the correct
> values for some variables, in most cases it should be possible to
> design this in such a way that it *just works* from a normal python
> interpreter with no additional variables set.
>
Fixing upstream is always best, but in the meantime is there some reason
that the Debian package doesn't just patch "sage/env.py" like Arch does?
Looking at the Arch approach, I checked that the following 3-line patch
causes 'python -c "import sage.all"' to succeed on Debian Sid with SageMath
8.4.
Best,
Nathan
--- env.py.orig 2019-01-03 05:15:59.0 -0600
+++ env.py 2019-01-10 12:28:13.0 -0600
@@ -118,10 +118,10 @@
_add_variable_or_fallback('LOCAL_IDENTIFIER','$HOSTNAME.%s'%os.getpid())
# bunch of sage directories and files
-_add_variable_or_fallback('SAGE_ROOT', None)
-_add_variable_or_fallback('SAGE_LOCAL', None)
+_add_variable_or_fallback('SAGE_ROOT', '/usr/share/sagemath')
+_add_variable_or_fallback('SAGE_LOCAL', '/usr')
_add_variable_or_fallback('SAGE_ETC',opj('$SAGE_LOCAL', 'etc'))
-_add_variable_or_fallback('SAGE_SCRIPTS_DIR',opj('$SAGE_LOCAL', 'bin'))
+_add_variable_or_fallback('SAGE_SCRIPTS_DIR',opj('$SAGE_ROOT', 'bin'))
_add_variable_or_fallback('SAGE_INC',opj('$SAGE_LOCAL', 'include'))
_add_variable_or_fallback('SAGE_SHARE', opj('$SAGE_LOCAL', 'share'))
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)
On Thursday, January 10, 2019 at 9:38:15 AM UTC-6, vdelecroix wrote: > > Could you repeat the order in which things are broken. > Any of the following sequences of commands will install both the SnapPy Python package and SageMath without producing any errors: 0) install python2 and python-pip 1) install snappy via pip 2) install sagemath via apt and 1) install sagemath via apt 2) install snappy via pip and 1) install sagemath via apt 2) source sage-env and install snappy via pip Independent of which route one takes above both of the following commands will succeed: A) sage -python -c "import snappy" B) source /usr/share/sagemath/bin/sage-env; python -c "import snappy" and this will always fail: C) python -c "import snappy" Best, Nathan -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)
On Thu, Jan 10, 2019 at 4:47 AM Nathan Dunfield wrote:
>
> I am a developer of the Python package "snappy" which acquires extra features
> when imported inside of Sage. Some of our Linux users have recently reported
> difficulties with SnapPy on machines where Sage was installed by the standard
> package manger making use of the system libraries and in particular the
> system python. I have reproduced the problem on Debian Sid but it also
> manifests itself on Fedora 28 [1]. The root of our problem is that in this
> situation:
>
> python -c "import sage.all"
>
> results the error:
>
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python2.7/dist-packages/sage/all.py", line 71, in
> from sage.env import SAGE_ROOT, SAGE_SRC, SAGE_DOC_SRC, SAGE_LOCAL,
> DOT_SAGE, SAGE_ENV
> File "/usr/lib/python2.7/dist-packages/sage/env.py", line 123, in
> _add_variable_or_fallback('SAGE_ETC',opj('$SAGE_LOCAL', 'etc'))
> File "/usr/lib/python2.7/dist-packages/sage/env.py", line 103, in
> _add_variable_or_fallback
> value = sep.join(components)
> TypeError: sequence item 0: expected string, NoneType found
>
> whereas
>
> sage -python -c "import sage.all"
>
> works as expected. Currently, our Python package tests for whether it is
> running in SageMath by:
>
> _within_sage = False
> try:
> import sage.all
> _within_sage = True
> except ImportError:
> pass
>
> One solution for us (I think) would be to simply catch and ignore all types
> of exceptions in the above block, but I was wondering if the current behavior
> of 'python -c "import sage.all"' was expected or is this possibly a bug? Or
> perhaps there is a work-around of some kind?
It's expected (see my previous reply) but obviously not great. For
now I would just rewrite your above test to catch Exception, instead
of just ImportError. This is a nitpick but instead of _within_sage I
would name that variable something like "_have_sage" instead: It's
just a test whether or not sage can be imported.
If you want to look-before-you-leap you could also check if
`SAGE_ROOT` and `SAGE_LOCAL` are set to something reasonable in
`os.environ`. Those are the two environment variables that currently
need to be set at a minimum for that module to work properly. But
even with that it would still be wise to catch exceptions anyways.
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)
On Thu, Jan 10, 2019 at 1:57 PM Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
>
> (side note)
>
> On archlinux that also uses system Python for Sage the
> situation is better: importing sage.all in Python2 does work! Even
> though the configuration constants are not in the environment! They
> are set up properly in sage_env.py that is part of the SageMath
> installation. And more precisely $SAGE_LOCAL fallsback to the default
> "/usr" which is what it is intend to be on archlinux.
>
> I don't understand why on Debian $SAGE_LOCAL is set to None and
> managed by environment variables.
I have mentioned elsewhere (e.g. on
https://trac.sagemath.org/ticket/22652) that the sage.env module ought
to be fixed upstream (that is, in the main Sage sources) so that it
can actually work properly without having to set any special
environment variables. Even if it has to guess in some cases, and has
to raise a RuntimeError if it can't reasonably guess the correct
values for some variables, in most cases it should be possible to
design this in such a way that it *just works* from a normal python
interpreter with no additional variables set.
> Le 10/01/2019 à 04:47, Nathan Dunfield a écrit :
> > I am a developer of the Python package "snappy" which acquires extra
> > features when imported inside of Sage. Some of our Linux users have
> > recently reported difficulties with SnapPy on machines where Sage was
> > installed by the standard package manger making use of the system libraries
> > and in particular the system python. I have reproduced the problem on
> > Debian Sid but it also manifests itself on Fedora 28 [1]. The root of our
> > problem is that in this situation:
> >
> > python -c "import sage.all"
> >
> > results the error:
> >
> > Traceback (most recent call last):
> >File "", line 1, in
> >File "/usr/lib/python2.7/dist-packages/sage/all.py", line 71, in
> > from sage.env import SAGE_ROOT, SAGE_SRC, SAGE_DOC_SRC, SAGE_LOCAL,
> > DOT_SAGE, SAGE_ENV
> >File "/usr/lib/python2.7/dist-packages/sage/env.py", line 123, in
> >
> > _add_variable_or_fallback('SAGE_ETC',opj('$SAGE_LOCAL', 'etc'))
> >File "/usr/lib/python2.7/dist-packages/sage/env.py", line 103, in
> > _add_variable_or_fallback
> > value = sep.join(components)
> > TypeError: sequence item 0: expected string, NoneType found
> >
> > whereas
> >
> > sage -python -c "import sage.all"
> >
> > works as expected. Currently, our Python package tests for whether it is
> > running in SageMath by:
> >
> > _within_sage = False
> > try:
> > import sage.all
> > _within_sage = True
> > except ImportError:
> > pass
> >
> > One solution for us (I think) would be to simply catch and ignore all types
> > of exceptions in the above block, but I was wondering if the current
> > behavior of 'python -c "import sage.all"' was expected or is this possibly
> > a bug? Or perhaps there is a work-around of some kind?
> >
> > Thanks,
> >
> > Nathan
> >
> > P.S. In the Debian package "sage" does not accept the "-pip" flag, even
> > though installing the "sagemath" package does pull in "pip" (tested on a
> > clear Sid Docker container). Why is this? I ask because our current
> > instructions for installing SnapPy into SageMath use "sage -pip".
> >
> >
> > [1] See the second comment, not the original report, on
> > https://bitbucket.org/t3m/snappy/issues/14/
> >
>
> --
> 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 sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)
Le 10/01/2019 à 16:01, Nathan Dunfield a écrit : On Thursday, January 10, 2019 at 6:47:33 AM UTC-6, vdelecroix wrote: Le 10/01/2019 à 04:47, Nathan Dunfield a écrit : P.S. In the Debian package "sage" does not accept the "-pip" flag, even though installing the "sagemath" package does pull in "pip" (tested on a clear Sid Docker container). Why is this? I ask because our current instructions for installing SnapPy into SageMath use "sage -pip". The sage script in Debian is indeed a restricted version of the original sage script (to avoid messing up with the system). You can just use the pip from the system. That works fine if you source the environment variables first: $ source /usr/share/sagemath/bin/sage-env $ pip install surface_dynamics --user Yes, snappy installs fine with the system pip (even without sourcing sage-env), though as you know from writing the flatsurf docs, this distinction rather complicates the installation instructions. Indeed. And this have to be discussed with Debian distribution as Dima pointed out. The (long term) answer will probably be: make snappy a proper Debian package in two versions "snappy" and "snappy-sagemath". Our issue reports have actually come from people who installed SnapPy in their system Python with pip only to have it crash when starting the SnapPy app because they had also previously installed Sage via their package manager. In other words, our "installing SnapPy in Linux (no Sage)" instructions will fail if user has previously installed Sage in a particular way. Could you repeat the order in which things are broken. Is this 1) install snappy via pip 2) install sagemath via apt 3) launch python and load snappy or/and 1) install sagemath via apt 2) install snappy via pip I believe the following should work 1) install sagemath via apt 2) source sage-env and install snappy via pip 3) launch sage and load snappy But might be broken when loading from python. Vincent -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)
On Thursday, January 10, 2019 at 6:47:33 AM UTC-6, vdelecroix wrote: > > Le 10/01/2019 à 04:47, Nathan Dunfield a écrit : > > > > P.S. In the Debian package "sage" does not accept the "-pip" flag, even > > though installing the "sagemath" package does pull in "pip" (tested on a > > clear Sid Docker container). Why is this? I ask because our current > > instructions for installing SnapPy into SageMath use "sage -pip". > > The sage script in Debian is indeed a restricted version of the > original sage script (to avoid messing up with the system). You > can just use the pip from the system. That works fine if you > source the environment variables first: > > $ source /usr/share/sagemath/bin/sage-env > $ pip install surface_dynamics --user > Yes, snappy installs fine with the system pip (even without sourcing sage-env), though as you know from writing the flatsurf docs, this distinction rather complicates the installation instructions. Our issue reports have actually come from people who installed SnapPy in their system Python with pip only to have it crash when starting the SnapPy app because they had also previously installed Sage via their package manager. In other words, our "installing SnapPy in Linux (no Sage)" instructions will fail if user has previously installed Sage in a particular way. Nathan -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)
(side note)
On archlinux that also uses system Python for Sage the
situation is better: importing sage.all in Python2 does work! Even
though the configuration constants are not in the environment! They
are set up properly in sage_env.py that is part of the SageMath
installation. And more precisely $SAGE_LOCAL fallsback to the default
"/usr" which is what it is intend to be on archlinux.
I don't understand why on Debian $SAGE_LOCAL is set to None and
managed by environment variables.
Le 10/01/2019 à 04:47, Nathan Dunfield a écrit :
I am a developer of the Python package "snappy" which acquires extra
features when imported inside of Sage. Some of our Linux users have
recently reported difficulties with SnapPy on machines where Sage was
installed by the standard package manger making use of the system libraries
and in particular the system python. I have reproduced the problem on
Debian Sid but it also manifests itself on Fedora 28 [1]. The root of our
problem is that in this situation:
python -c "import sage.all"
results the error:
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/dist-packages/sage/all.py", line 71, in
from sage.env import SAGE_ROOT, SAGE_SRC, SAGE_DOC_SRC, SAGE_LOCAL,
DOT_SAGE, SAGE_ENV
File "/usr/lib/python2.7/dist-packages/sage/env.py", line 123, in
_add_variable_or_fallback('SAGE_ETC',opj('$SAGE_LOCAL', 'etc'))
File "/usr/lib/python2.7/dist-packages/sage/env.py", line 103, in
_add_variable_or_fallback
value = sep.join(components)
TypeError: sequence item 0: expected string, NoneType found
whereas
sage -python -c "import sage.all"
works as expected. Currently, our Python package tests for whether it is
running in SageMath by:
_within_sage = False
try:
import sage.all
_within_sage = True
except ImportError:
pass
One solution for us (I think) would be to simply catch and ignore all types
of exceptions in the above block, but I was wondering if the current
behavior of 'python -c "import sage.all"' was expected or is this possibly
a bug? Or perhaps there is a work-around of some kind?
Thanks,
Nathan
P.S. In the Debian package "sage" does not accept the "-pip" flag, even
though installing the "sagemath" package does pull in "pip" (tested on a
clear Sid Docker container). Why is this? I ask because our current
instructions for installing SnapPy into SageMath use "sage -pip".
[1] See the second comment, not the original report, on
https://bitbucket.org/t3m/snappy/issues/14/
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)
Le 10/01/2019 à 04:47, Nathan Dunfield a écrit : P.S. In the Debian package "sage" does not accept the "-pip" flag, even though installing the "sagemath" package does pull in "pip" (tested on a clear Sid Docker container). Why is this? I ask because our current instructions for installing SnapPy into SageMath use "sage -pip". The sage script in Debian is indeed a restricted version of the original sage script (to avoid messing up with the system). You can just use the pip from the system. That works fine if you source the environment variables first: $ source /usr/share/sagemath/bin/sage-env $ pip install surface_dynamics --user Best wishes Vincent -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)
Dear Nathan,
I think that the cause of the trouble is that in Debian if you
start Python and try "import sage" it will fail. You first need
to set up some environment variables via
$ source /usr/share/sagemath/bin/sage-env
Best
Vincent
PS: I ran into that with surface_dynamics
https://gitlab.com/videlec/surface_dynamics
Le 10/01/2019 à 04:47, Nathan Dunfield a écrit :
I am a developer of the Python package "snappy" which acquires extra
features when imported inside of Sage. Some of our Linux users have
recently reported difficulties with SnapPy on machines where Sage was
installed by the standard package manger making use of the system libraries
and in particular the system python. I have reproduced the problem on
Debian Sid but it also manifests itself on Fedora 28 [1]. The root of our
problem is that in this situation:
python -c "import sage.all"
results the error:
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/dist-packages/sage/all.py", line 71, in
from sage.env import SAGE_ROOT, SAGE_SRC, SAGE_DOC_SRC, SAGE_LOCAL,
DOT_SAGE, SAGE_ENV
File "/usr/lib/python2.7/dist-packages/sage/env.py", line 123, in
_add_variable_or_fallback('SAGE_ETC',opj('$SAGE_LOCAL', 'etc'))
File "/usr/lib/python2.7/dist-packages/sage/env.py", line 103, in
_add_variable_or_fallback
value = sep.join(components)
TypeError: sequence item 0: expected string, NoneType found
whereas
sage -python -c "import sage.all"
works as expected. Currently, our Python package tests for whether it is
running in SageMath by:
_within_sage = False
try:
import sage.all
_within_sage = True
except ImportError:
pass
One solution for us (I think) would be to simply catch and ignore all types
of exceptions in the above block, but I was wondering if the current
behavior of 'python -c "import sage.all"' was expected or is this possibly
a bug? Or perhaps there is a work-around of some kind?
Thanks,
Nathan
P.S. In the Debian package "sage" does not accept the "-pip" flag, even
though installing the "sagemath" package does pull in "pip" (tested on a
clear Sid Docker container). Why is this? I ask because our current
instructions for installing SnapPy into SageMath use "sage -pip".
[1] See the second comment, not the original report, on
https://bitbucket.org/t3m/snappy/issues/14/
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
