I think this is a non-trivial dependency of Sage. Is it known that this
is a dependency? Should it be documented in the install guide?
I'm slightly confused because we had some discussion on this mailing
list about removing GNUTLS and requiring OpenSSL. But if we already
require OpenSSL, there was not much to discuss...
I've never had a problem with having hashlib on OSX 10.6.8, and I don't
think I installed any new libraries to get it. I think I concluded a
long time ago that this was a non-issue on OSX (10.6).
Jason
I consider this to be a bug in Python. Put some random file at
/usr/lib/libssl.so and Python thinks you have OpenSSL installed. This
will cause the build of hashlib to fail.
Context: I'm trying to "cross-compile" a 32-bit Sage on a 64-bit Linux
system. The Python installer looks at the 64-bit libraries to determine
its linker flags.
>
> I thought HTTPS (which requires SSL of course) wasn't strictly needed
> in Sage, but since it is omnipresent (many Python packages use it), it
> doesn't make sense to not have it. I.e., people frequently happen to
> notice they don't have _ssl *after* they've built Sage's Python
> package without SSL support.
Indeed: every time I build my working copy of Sage (not counting test
version here) I have to do first sage -i openssl and then sage -f
python to rebuild python. Otherwise some mercurial stuff does not
work (complains of not having _ssl, I think). The sort of thing which
does not work is pull/push requests froma remote repository.
This is a real nuisance, and I have long wanted a way to get this
built when I first build Sage, and not as an afterthought. If the
current discussion will help that, I would be grateful! (Also if
anyone can say what magic would make this work with Sage as currently
organised.)
John
The git spkg I just made is unable to communicate with repositories over
HTTP (unless you just happen to have libcurl and libexpat installed
systemwide - I didn't want to package them since libcurl's source code
is almost as large again as git's; I didn't look at libexpat).
Would this be a problem for you once we switch to git? What do you use
Sage's Mercurial for which requires pushing and pulling to/from a remote
repository?
-Keshav
----
Join us in #sagemath on irc.freenode.net !
All advertising materials mentioning features or use of this * software must display the following acknowledgment:
He uses
http://code.google.com/p/lmfdb/issues/list
and
http://code.google.com/p/purplesage/
which both *require* https for pushing (though not for pulling if you
url hack).
William
>
> -Keshav
>
> ----
> Join us in #sagemath on irc.freenode.net !
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
? Can you provide a reference? I thought the mainissue with
gnuplot's weird GPL-incomplate license is that only the original
authors are allowed to initiate distribution of modified versions of
the source; anybody else must distribute the unchanged sources +
patches.
> Maybe it would be helpful to email
> those developers, what they say about this and us including openssl in sage.
Maybe we can include openssl in Sage as long as no GPL'd components of
Sage binary link with it... but that is a fine line. Linking against
it as a system library is less of a fine line.
>
> H
Sorry - I mean, *over HTTP(S)*.
Correct: it's to use google code.
I don't mind the openssl not beeing included by default for license
reasons. But it would be good if I could (say by setting an
environment variable or in .sagerc file or similar) record my choice
to include openssl *once and for all*, so that whenever I build Sage
it has it in it.
John
? Can you provide a reference?
I guess Purple Sage will have to switch to git when Sage does, since
their code bases are deeply connected. lmfdb, which I hadn't heard of
before, looks to be a separate codebase (like sagenb is). Is it
switching to git too? If not, then do we still need to ship Mercurial in
Sage to allow people to hack on lmfdb, or will they need to start using
systemwide versions of Mercurial?
... or will they need to start using
systemwide versions of Mercurial?
Actually, the code base of psage is not "deeply connected" to sage. It
really is just a python library that more or less depends on "all" of
sage being present. (Or at least a lot of sage.) It could probably
switch to git without much of an issue. As for the LMFDB, I haven't
really thought about it at all. I would like it if it used git, but
I'm not going push for people to switch without much reason.
I don't think Sage _needs_ to ship mercurial if it switches to git,
but it would be nice for me, and probably other, if it did. As I've
noted before, mercurial seems to be a PITA to build from source when I
don't have root access, and the last time I tried to do it I gave up
and decided to use Sage's mercurial. (git was easy to build, though.)
In this (still hypothetical) situation, since most of the work has
already been done, mercurial could probably also just stick around as
an optional package, at least until it breaks from lack of
maintenance.
I see. Makes sense.
> I don't think Sage _needs_ to ship mercurial if it switches to git,
> but it would be nice for me, and probably other, if it did. As I've
> noted before, mercurial seems to be a PITA to build from source when I
> don't have root access, and the last time I tried to do it I gave up
> and decided to use Sage's mercurial. (git was easy to build, though.)
By the way, I've noticed many people saying "Sage should provide X as an
SPKG because it is difficult for me to build X otherwise, not that Sage
really has much of a dependency on X." I think this is exactly the
problem that switching to Prefix would solve. For such packages, you
could just grab an ebuild from the Gentoo people and stick it in Sage,
rather than needing a Sage developer to create an SPKG for you.
> In this (still hypothetical) situation, since most of the work has
> already been done, mercurial could probably also just stick around as
> an optional package, at least until it breaks from lack of
> maintenance.
Fair enough.
Why don't such people just use Prefix already then? If Prefix solves
this problem why do we have to deal with it? This might be a
rhetorical question....
> For such packages, you
> could just grab an ebuild from the Gentoo people and stick it in Sage,
> rather than needing a Sage developer to create an SPKG for you.
>
>> In this (still hypothetical) situation, since most of the work has
>> already been done, mercurial could probably also just stick around as
>> an optional package, at least until it breaks from lack of
>> maintenance.
>
> Fair enough.
>
> -Keshav
>
> ----
> Join us in #sagemath on irc.freenode.net !
>
I assume you mean, use Prefix independently of Sage, since "official"
Sage doesn't use Prefix yet, and unofficial Prefix-using versions of
Sage (i.e. lmonade) are experimental and don't pass tests.
1. Prefix is difficult to set up and install. There's no easy installer
or single command you can run to do it.
2. Prefix bootstraps almost everything from scratch, which is not worth
it for many people.
3. Maybe people don't know about Prefix, and as Sage developers their
main exposure to a mini-distribution sitting in a folder is Sage
itself. Or maybe they don't want to have *two* mini-distributions
sitting in folders on their computer.
Addressing the first two is, I think, one of Burcin's main goals for
lmonade, and he's made quite some progress on both of them. lmonade
installs with a single command, and uses the system toolchain (afaik).
But in upstream, Sage-unrelated Gentoo Prefix, those two points are
still big problems for the use case I mention.
I think (1) is the only realistic solution.
(2) has serious license issues.
Regarding (3), there is already an openssl optional package, FWIW.
-- William
I believe the pyOpenSSL and openid flask plugin couldn't be installed
either, and of course, the notebook wouldn't have openid or https
support without openssl.
Of course, it's easier for us to do option (1). OpenSSL (not just the
libs, but the development headers) comes standard on OSX and many other
OSs, but Jeroen's testing has uncovered several systems that don't have
the OpenSSL dev headers installed by default.
I vote for option 1. We already require non-standard packages that
people need to install in order to compile or run Sage---this would just
add one more very standard dependency. If someone had a convincing
argument for how hard it is to install OpenSSL on a system that doesn't
have it installed already, I'm not absolutely fixed on option 1.
Thanks,
Jason