Re: [sage-devel] Re: Notebook stuck on "N?" with a worksheet

[Jori Mäntysalo]

On Sun, 23 Oct 2016, Luca De Feo wrote:


When I want to share a notebook with the students, I share a static
.ipynb file via gist, and visualize it via nbviewer. e.g.:

 http://nbviewer.jupyter.org/gist/defeo/4adb727f7608dfd2c75eb7699d670fb7

When I want to see the student's work, I ask them to send me the
.ipynb by mail, or directly access their notebooks using my admin
account.

Works like a charm.


OK, sounds possible to do. But document sharing between researchers still 
does not work. (But to be honest, only sharing so far here has been me 
replying to request like "Can you test this hypothesis?". Maybe some 
day...)


--
Jori Mäntysalo

Re: [sage-devel] add curl as a standard package

[Emmanuel Charpentier]

Le mercredi 26 octobre 2016 00:42:01 UTC+2, John H Palmieri a écrit :
>
> I have no opinion on whether this approach is on the whole a good idea, 
> but I will point out that "which curl" is not as portable as "command -v 
> curl". We had an issue a while ago with "which" not behaving properly on 
> some platform -- maybe on Solaris "which blah" had a return status of 0 
> even if "blah" was not present? I forget. 
>

Note that we don't use the return status, but the path expansion. I've no 
idea about the portability of both ; I note that which is a standard 
binary, whereas command is internal to bash. Pick your portability poison...
 

> Anyway, if nothing else, try "command -v ..." instead of "which ...".
>

Easy to do.
 

> (And would it be even better to try to run curl to make sure it functions 
> properly, instead of just seeing if it's present?)
>

That's another can of worms. I'm trying to satisfy R's requirements ; the 
function of the installed package can be tested with the package test suite 
(sage -i -c...). Maintaining  the user's systemwide installation is out of 
Sage's scope.

The alternative is, of course, to install curl unconditionally. And the 
same could be said about xz and pcre, two other new R prerequisites...

--
Emmanuel Charpentier

>
>   John
>
>
> On Tuesday, October 25, 2016 at 2:52:34 PM UTC-7, Emmanuel Charpentier 
> wrote:
>>
>> This is now Trac#21767 . The 
>> unconditional installation works okay on top of 7.5beta0.
>>
>> The conditional installation can probably be obtained with this bash 
>> snippet, at the top of spkg-install :
>>
>> ## Installation de curl...
>>
>> ## Look for a systemwide installation
>>
>> LibExists=no
>> if $(pkg-config --exists libcurl) ; then
>> LibExists=yes
>> echo A systemwide version of libcurl exists. Testing it.
>> else
>> echo "No systemwide curl installation (or not using pkg-config)."
>> fi
>>
>> ## Systemwide installation version check
>>
>> VersOK=no
>> if test $LibExists = yes ; then
>> if ! test "7.28.0" ">" $(pkg-config --modversion libcurl) ; then
>> echo Systemwide installation of libcurl is enough to support R.
>> VersOK=yes
>> else 
>> echo Systemwide version of libcurl too old to support our R.
>> fi
>> fi
>>
>> ## Checking for a systemwide executable
>>
>> ExecOK=no
>> if test $VersOK = yes ; then
>> if test X$(which curl)X = XX ; then
>> echo No systemwide curl executable in PATH.
>> else
>> echo Systemwide curl executable found.
>> ExecOK=yes
>> fi
>> fi
>>
>> if test $ExecOK = yes ; then
>> echo No local installation required.
>> exit 0
>> else
>> echo Starting curl installation...
>> fi
>>
>> The same tachnique can probably been used for xz. pcre will need a 
>> supplemental step (checking configuration).
>>
>> What do you think ?
>>
>> --
>> Emmanuel Charpentier
>>
>> Le mardi 25 octobre 2016 11:15:56 UTC+2, Jean-Pierre Flori a écrit :
>>>
>>>
>>>
>>> On Tuesday, October 25, 2016 at 11:11:38 AM UTC+2, Jean-Pierre Flori 
>>> wrote:



 On Tuesday, October 25, 2016 at 12:48:39 AM UTC+2, Dima Pasechnik wrote:
>
>
>
> On Monday, October 24, 2016 at 9:45:18 PM UTC, Emmanuel Charpentier 
> wrote:
>>
>> Okay. I I have followed you correctly, we have two (mutually 
>> incompatible) options :
>>
>>
>>- (Dima's option) : package curl, pcre and xz as standard 
>>packages, and make R depend on them (unconditionnally).
>>- (Jean-Pierre option) : add tjem to Sage's core, but build them 
>>if and only if they are not installed systemwide (= useable at Sage's 
>>compile time) ; do this before trying to build R.
>>
>> The first option is extremely simple and failsafe. The cost is about 
>> 15 MB (sum of all installed files in a temporary "prefix" directory, 
>> without shaving anything) and about 3 minutes of compilation time (no 
>> parallelism used). We might shave 4,9 MB of docs (local/share/(doc|man). 
>> Binaries are  about 0.9MB. The total potential cots (sum of sizes of the 
>> three build directories) is 89 MB (= potential cost if the three build 
>> directories ate kept after building i. e. for debugging purposes).
>>
>
> I don't really follow you: note that gcc is also a standard package, 
> but it only really gets installed if the system gcc is 
> not good enough. That is to say, if curl, pcre, and xz are available 
> system-wide, Sage should not try to install them,
> no megabytes used...
>
 I don't think the real issue is megabytes, but rather making sage more 
 modular and easier to ship into distributions (other than 
 sage-the-distrib).
  

>  
>
>>
>> The second one requires hacking the main Sage configuration. I do not 
>> feel currently quite at ease with this one, but I'm just reading the 
>> relevant 

[sage-devel] Re: Can we depend on system's utilities and libraries ?

[Emmanuel Charpentier]

It looks that this is a general issue, about which I do not know enough 
(yet) to contribute usefully, and which largely surpasses the R update 
issue I was tackling.

Therefore, I suggest to treat the latter, lesser issue in the current 
framework (i. e. no conditional installation for package), and consider 
overhauling this framework as a more general problem.

--
Emmanuel Charpentier

Le mercredi 26 octobre 2016 15:16:31 UTC+2, Jean-Pierre Flori a écrit :
>
>
>
> On Wednesday, October 26, 2016 at 3:01:48 PM UTC+2, Jean-Pierre Flori 
> wrote:
>>
>>
>>
>> On Wednesday, October 26, 2016 at 2:58:44 PM UTC+2, Jean-Pierre Flori 
>> wrote:
>>>
>>>
>>>
>>> On Wednesday, October 26, 2016 at 2:22:45 PM UTC+2, Jean-Pierre Flori 
>>> wrote:



 On Wednesday, October 26, 2016 at 2:08:25 PM UTC+2, Emmanuel 
 Charpentier wrote:
>
>
>
> Le mercredi 26 octobre 2016 13:40:14 UTC+2, Jean-Pierre Flori a écrit :
>>
>> It would be great to let the user choose when to use system libraries 
>> instead of building our own, whether its curl or gmp.
>> A problem coming to my mind to have a simple 
>> --with-curl=[system|build] working.
>>
>
> That means, if I follow you, to have to patch each and every 
> (candidate) package potentially using curl in order to consider this 
> flag. 
> Not exactly low-maintainance... 
>
 What do we gain ?
>
 I don't get you.

 The current situation is that for every package built by Sage depending 
 on any other package built by Sage, we have to tell them to look into 
 $SAGE_LOCAL for including headers and linking to libraries.

 I suggest to add a --with-curl=... or --with-systemwide-pkgs=... option 
 to the toplevel configure of "Sage the distribution" to tell "Sage the 
 distribution" not to build its own curl but to rely on a system wide one.
 But then we have to tell each package built by "Sage the distribution" 
 to look for its dependencies either in $SAGE_LOCAL (which is basically 
 always the case at the moment) or in standard system-wide paths (hopefully 
 we won't support non standard paths in the near future).

 So we indeed need to modify the configure options in each spkg-install 
 scripts of pkgs depending on curl to have "--with-curl=`pkgconfig 
 --blablbabla`" or anything sensible which would tell it to either look 
 into 
 $SAGE_LOCAL or in default paths.
 The only other way to do this without passing stuff to configure 
 scripts of each package is playing with LDFLAGS and CFLAGS and this has 
 unfortunately less chances of success than using configure scripts 
 options, 
 good luck with that.


> Furthermore, that introduce the possibility of having *simultaneously* 
> some packages using  our version of curl and others using system's 
> version. 
> Ouch...
>
> Yes maybe.
 I can surely make it so that Sage gets both ATLAS and openblas 
 installed if I really want to and link to both of them in a random way. 

 A more consistent way would be to pass a flag to curl's installation 
> script telling it to fake installation or to force build. That is 
> possible, 
> but, again, not very consistent with the primitive idea of enforcing some 
> consistency.
>
 No it does not solve the issue of packages having to link to libcurl. 
 Unless you want to play with LDFLAGS and C[...]FLAGS rather than 
 passing options to configure scripts of these packages.

>>> In fact you still have to deal with LDFLAGS and CPPFLAGS.
>>> At least R only looks in what they define and you cannot give anything 
>>> through a --with-curl= option.
>>>
>>> By the way it seems that Sage modifies by default LDFLAGS globally to 
>>> include $SAGE_LOCAL/lib but not CPPFLAGS. 
>>>
>>
>> Maybe we can use config.site as well:
>>
>> https://www.gnu.org/software/automake/manual/html_node/config_002esite.html 
>>
>
> We set CPATH, but I'm not sure it is enough for autotools.
>

-- 
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] Re: Can we depend on system's utilities and libraries ?

[Jeroen Demeyer]

On 2016-10-26 20:02, Jean-Pierre Flori wrote:

Sure. What you uncovered here is larger than R.


At least there is a framework now for conditionally installing standard 
packages (like gcc).


--
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.

[sage-devel] Re: add pcre as a standard package

[Emmanuel Charpentier]

An initial packaging (Trac#21770 ), 
without attemt to autodetect a system version, needs your review.

Le lundi 24 octobre 2016 12:12:01 UTC+2, Emmanuel Charpentier a écrit :
>
> [ Same problem as for curl, posted a few seconds ago ]
>
> It looks like pcre  , which 
> was formerly installed by R installation, must now be installed 
> 
>  
> in order to install R.
>
> One can note that a problem will rarely exists, since most Sage users have 
> curl installed in their system. However, a user having only sage installed 
> (e. g. Sage's virtual machine for Windows) will see it...
>
> If we want to keep R a standard package, we have to either
>
>- patch R and add curl's installation (heavy : the R core Team threw 
>the towel on it),
>- add curl to Sage's prerequisites (lighter to us, but still heavy to 
>the users), 
>- or make it a standard package, on which R must depend.
>
>
> The latter solution has my reference(much simpler).
>
> What is yours ?
>
> --
> Emmanuel Charpentier
>

-- 
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] Can we depend on system's utilities and libraries ?

[Francois Bissey]

Yup. It is all system packages. In fact R and its dependencies
are not part of the sage-on-gentoo “repo”.
Also in Gentoo we don’t usually split things in $package and
$package-devel you get the nice libraries for linking and headers.

The headers and stuff in $package-devel is the sticky point
when requiring $package from the host distro.
You most certainly will have curl, openssl, xz and pcre installed.
And equally unless you chose a “develop” configuration you’ll
have very few of the necessary devel packages. Which is a problem 
for anyone without admin access on their machines. Mind you
some compiler requirements may now enter the same category,
we do have messages from people who have a C compiler but
didn’t install a C++ one from time to time.

Ideally for those in particular it would be best to go with your
distro in my opinion. How many people have a linux box without
some kind of admin access?

François


> On 27/10/2016, at 00:57, Jean-Pierre Flori  wrote:
> 
> And i guess sage-on-gentoo just puts everything into standard paths.
> 
> -- 
> 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] add curl as a standard package

[Emmanuel Charpentier]

On 26/10/2016 09:59, Jean-Pierre Flori wrote:



On Wednesday, October 26, 2016 at 9:24:35 AM UTC+2, Emmanuel Charpentier
wrote:

Le mercredi 26 octobre 2016 09:18:06 UTC+2, Jeroen Demeyer a écrit :

On 2016-10-25 23:52, Emmanuel Charpentier wrote:
> This is now Trac#21767 >. The
> unconditional installation works okay on top of 7.5beta0.
>
> The conditional installation can probably be obtained with
this bash
> snippet, at the top of spkg-install :

Unless there is a good reason to do otherwise, such checks are
better
done in the top-level configure instead.


I'm not so sure : harder to do, harder to understand, not obvious at
reading the spkg-install script. But cleaner, indeed.

One good reason is that when two packages will depend on curl we don't
need to duplicate code.


??? I don't understand your point : the code being at the top of curl's 
spkg-install script, it has not to be duplicated (nor executed twice : 
curl would be marked as installed, and packages depending on it wouldn't 
trigger it twice.


Putting something analogous in the main (Sage's) configure scriptt would 
mean integrating curl in Sage itself. R being a standard package and 
depending on curl, it would amount to the same thing. In which case, 
"packaging" curl (i. e. create a distinct software entity) is nonsense ; 
just add it to  Sage's source tarball and, indeed, add the necessray 
voodoo in configure (or, rather, to its sources, if any).


I'm not sure I'm following you...

Furthermore :



BTW, I'm having second thoughts on the wisdom of installing
conditionally to the current system's state. I'll open the
discussion in another thread.


--
Emmanuel Charpentier

--
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.

[sage-devel] Can we depend on system's utilities and libraries ?

[Emmanuel Charpentier]

Dear list,

It has been proposed that we could use the system's version of some 
utilities in order to lighten Sage's weight.

Case in point : R ceased recently to provide its own version of xz, curl 
and pcre, which we must now either provide or add to Sage's prerequisites 
list.


   - Providing R's prerequisites has the advantage of being consistent : 
   one could install a Sage binary without having to install those 
   prerequisites first. On the other hand, we could duplicate unnecessarily 
   existing functionality. Nevertheless, that is currently our policy : for 
   example, we install R and Maxima whether or not they are present 
   systemwide...
   - One could install them conditionally to not being present systemwide, 
   avoiding duplication : see this thread 
    for an 
   example. But we loose the consistency.
   - The Sage list is quite short, and is essentially a list of what is 
   necessary to bootstrap Sage successfully : we do not necessarily rely on 
   the system's version,as illustrated by gcc case : we use the system's 
   version to bootstrap, but install our own if necessary. Adding 
   non-bootstrap prerequisites to this list is a break of our current policy. 
   But it can lighten the resulting installation.


In the case in point, xz has been packaged (Trac#21063 
) as an optional package ; curl is 
in the process of being packaged (Trac#21767 
) and a (trivial) packaging of pcre 
is under way. The question is what to do with such prerequisites :

   - install them unconditionnaly
   - install them if not present and sufficient systemwide
   - add them to Sage's prerequisites

What is your advice ?

--
Emmanuel Charpentier

-- 
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] add curl as a standard package

[Jean-Pierre Flori]

On Wednesday, October 26, 2016 at 9:24:35 AM UTC+2, Emmanuel Charpentier 
wrote:
>
> Le mercredi 26 octobre 2016 09:18:06 UTC+2, Jeroen Demeyer a écrit :
>>
>> On 2016-10-25 23:52, Emmanuel Charpentier wrote: 
>> > This is now Trac#21767 . The 
>> > unconditional installation works okay on top of 7.5beta0. 
>> > 
>> > The conditional installation can probably be obtained with this bash 
>> > snippet, at the top of spkg-install : 
>>
>> Unless there is a good reason to do otherwise, such checks are better 
>> done in the top-level configure instead. 
>>
>
> I'm not so sure : harder to do, harder to understand, not obvious at 
> reading the spkg-install script. But cleaner, indeed.
>
> One good reason is that when two packages will depend on curl we don't 
need to duplicate code.

> BTW, I'm having second thoughts on the wisdom of installing conditionally 
> to the current system's state. I'll open the discussion in another thread.
>
> --
> Emmanuel Charpentier
>

-- 
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] add curl as a standard package

[Emmanuel Charpentier]

See this thread 
.

--
Emmanuel Charpentier

Le mercredi 26 octobre 2016 09:24:35 UTC+2, Emmanuel Charpentier a écrit :
>
> Le mercredi 26 octobre 2016 09:18:06 UTC+2, Jeroen Demeyer a écrit :
>>
>> On 2016-10-25 23:52, Emmanuel Charpentier wrote: 
>> > This is now Trac#21767 . The 
>> > unconditional installation works okay on top of 7.5beta0. 
>> > 
>> > The conditional installation can probably be obtained with this bash 
>> > snippet, at the top of spkg-install : 
>>
>> Unless there is a good reason to do otherwise, such checks are better 
>> done in the top-level configure instead. 
>>
>
> I'm not so sure : harder to do, harder to understand, not obvious at 
> reading the spkg-install script. But cleaner, indeed.
>
> BTW, I'm having second thoughts on the wisdom of installing conditionally 
> to the current system's state. I'll open the discussion in another thread.
>
> --
> Emmanuel Charpentier
>

-- 
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] add curl as a standard package

[Jean-Pierre Flori]

On Wednesday, October 26, 2016 at 11:18:15 AM UTC+2, Emmanuel Charpentier 
wrote:
>
> On 26/10/2016 09:59, Jean-Pierre Flori wrote: 
> > 
> > 
> > On Wednesday, October 26, 2016 at 9:24:35 AM UTC+2, Emmanuel Charpentier 
> > wrote: 
> > 
> > Le mercredi 26 octobre 2016 09:18:06 UTC+2, Jeroen Demeyer a écrit : 
> > 
> > On 2016-10-25 23:52, Emmanuel Charpentier wrote: 
> > > This is now Trac#21767  > >. The 
> > > unconditional installation works okay on top of 7.5beta0. 
> > > 
> > > The conditional installation can probably be obtained with 
> > this bash 
> > > snippet, at the top of spkg-install : 
> > 
> > Unless there is a good reason to do otherwise, such checks are 
> > better 
> > done in the top-level configure instead. 
> > 
> > 
> > I'm not so sure : harder to do, harder to understand, not obvious at 
> > reading the spkg-install script. But cleaner, indeed. 
> > 
> > One good reason is that when two packages will depend on curl we don't 
> > need to duplicate code. 
>
> ??? I don't understand your point : the code being at the top of curl's 
> spkg-install script, it has not to be duplicated (nor executed twice : 
> curl would be marked as installed, and packages depending on it wouldn't 
> trigger it twice. 
>
> Putting something analogous in the main (Sage's) configure scriptt would 
> mean integrating curl in Sage itself. R being a standard package and 
> depending on curl, it would amount to the same thing. In which case, 
> "packaging" curl (i. e. create a distinct software entity) is nonsense ; 
> just add it to  Sage's source tarball and, indeed, add the necessray 
> voodoo in configure (or, rather, to its sources, if any). 
>
> I'm not sure I'm following you... 
>
nah it was morning,I thought you  meant at top of the R spkg-install script.

>
> Furthermore : 
>
> > 
> > BTW, I'm having second thoughts on the wisdom of installing 
> > conditionally to the current system's state. I'll open the 
> > discussion in another thread. 
>
> -- 
> Emmanuel Charpentier 
>
>

-- 
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] add curl as a standard package

[Jeroen Demeyer]

On 2016-10-25 23:52, Emmanuel Charpentier wrote:

This is now Trac#21767 . The
unconditional installation works okay on top of 7.5beta0.

The conditional installation can probably be obtained with this bash
snippet, at the top of spkg-install :


Unless there is a good reason to do otherwise, such checks are better 
done in the top-level configure instead.


--
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] add curl as a standard package

[Jeroen Demeyer]

On 2016-10-26 09:24, Emmanuel Charpentier wrote:

I'm not so sure : harder to do, harder to understand, not obvious at
reading the spkg-install script. But cleaner, indeed.


Plus, it allows for explicit installation if you want to install it 
anyway. It's nice for example that `./sage -i gcc` does install gcc, 
regardless of whether you need it or not.


If the check would be in the spkg-install script of curl, then `./sage 
-i curl` would *not* install curl.


--
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.

[sage-devel] Re: add curl as a standard package

[Emmanuel Charpentier]

Le mercredi 26 octobre 2016 03:12:04 UTC+2, Volker Braun a écrit :
>
> One issue with curl is that you sooner or later will need the root 
> certificates to use it, namely when you start downloading from a https 
> site. E.g. in hashstack I recently added the root certs:
>
> https://github.com/hashdist/hashstack/issues/969
>
> This issue already faces us with openssl but since we actually don't use 
> it much we could avoid it so far. But when replacing curl in the PATH we 
> are going to run into that issue.
>

This issue is *distinct* from the one I'm trying to solve (iL e. satisfy 
R's prerequisites). Should't you open a relevant ticket ? 

>
> I would be happy with adding curl (and up-to-date root certificates) to 
> the list of system requirements for building Sage and avoid that can of 
> worms.
>

That would be a good solution, but a bit at ill ease with the "batteries 
included" motto. Ditto for possible addition of xz and pcre. 

>
> PS: and no, you can't use the OS-provided certs, since Apple had to cook 
> their own sauce once more.
>

 BTW, what is the point of buying an expensive Mac for running 
Sage ?

--
Emmanuel Charpentier
 

>
>
> On Monday, October 24, 2016 at 6:09:24 AM UTC-4, Emmanuel Charpentier 
> wrote:
>>
>> It looks like curl , which was formerly installed 
>> by R installation, must now be installed 
>> 
>>  
>> in order to install R.
>>
>> One can note that a problem will rarely exists, since most Sage users 
>> have curl installed in their system. However, a user having only sage 
>> installed (e. g. Sage's virtual machine for Windows) will see it...
>>
>> If we want to keep R a standard package, we have to either
>>
>>- patch R and add curl's installation (heavy : the R core Team threw 
>>the towel on it),
>>- add curl to Sage's prerequisites (lighter to us, but still heavy to 
>>the users), 
>>- or make it a standard package, on which R must depend.
>>
>>
>> The latter solution has my reference(much simpler).
>>
>> What is yours ?
>>
>> --
>> Emmanuel Charpentier
>>
>

-- 
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] add curl as a standard package

[Emmanuel Charpentier]

Le mercredi 26 octobre 2016 09:18:06 UTC+2, Jeroen Demeyer a écrit :
>
> On 2016-10-25 23:52, Emmanuel Charpentier wrote: 
> > This is now Trac#21767 . The 
> > unconditional installation works okay on top of 7.5beta0. 
> > 
> > The conditional installation can probably be obtained with this bash 
> > snippet, at the top of spkg-install : 
>
> Unless there is a good reason to do otherwise, such checks are better 
> done in the top-level configure instead. 
>

I'm not so sure : harder to do, harder to understand, not obvious at 
reading the spkg-install script. But cleaner, indeed.

BTW, I'm having second thoughts on the wisdom of installing conditionally 
to the current system's state. I'll open the discussion in another thread.

--
Emmanuel Charpentier

-- 
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.

[sage-devel] Re: Can we depend on system's utilities and libraries ?

[Jean-Pierre Flori]

It would be great to let the user choose when to use system libraries 
instead of building our own, whether its curl or gmp.
A problem coming to my mind to have a simple --with-curl=[system|build] 
working.

For packages that will still be built and use curl, what we currently do, 
at least for packages using autotools or standard configure/make/make 
install strategies, is that we pass --with-curl=$SAGE_LOCAL or something 
like that.
Now if we allow curl to be either in $SAGE_LOCAL or in a sytem-wide default 
path we cannot go this way.

Using --with-curl=`pkgconfig --lib curl` (or whatever pkgconfig syntax is) 
might do the trick for libs providing pkgconfig files (once we make sure 
Sage or systemwide pkgconfig looks first in $SAGE_LOCAL, then in systemwide 
dirs).

Another solution is to globally tweak CFLAGS and LDFLAGS but that will be 
hell.

How does sage-on-gentoo deal with this?

-- 
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.

[sage-devel] Re: Can we depend on system's utilities and libraries ?

[Jean-Pierre Flori]

On Wednesday, October 26, 2016 at 3:01:48 PM UTC+2, Jean-Pierre Flori wrote:
>
>
>
> On Wednesday, October 26, 2016 at 2:58:44 PM UTC+2, Jean-Pierre Flori 
> wrote:
>>
>>
>>
>> On Wednesday, October 26, 2016 at 2:22:45 PM UTC+2, Jean-Pierre Flori 
>> wrote:
>>>
>>>
>>>
>>> On Wednesday, October 26, 2016 at 2:08:25 PM UTC+2, Emmanuel Charpentier 
>>> wrote:



 Le mercredi 26 octobre 2016 13:40:14 UTC+2, Jean-Pierre Flori a écrit :
>
> It would be great to let the user choose when to use system libraries 
> instead of building our own, whether its curl or gmp.
> A problem coming to my mind to have a simple 
> --with-curl=[system|build] working.
>

 That means, if I follow you, to have to patch each and every 
 (candidate) package potentially using curl in order to consider this flag. 
 Not exactly low-maintainance... 

>>> What do we gain ?

>>> I don't get you.
>>>
>>> The current situation is that for every package built by Sage depending 
>>> on any other package built by Sage, we have to tell them to look into 
>>> $SAGE_LOCAL for including headers and linking to libraries.
>>>
>>> I suggest to add a --with-curl=... or --with-systemwide-pkgs=... option 
>>> to the toplevel configure of "Sage the distribution" to tell "Sage the 
>>> distribution" not to build its own curl but to rely on a system wide one.
>>> But then we have to tell each package built by "Sage the distribution" 
>>> to look for its dependencies either in $SAGE_LOCAL (which is basically 
>>> always the case at the moment) or in standard system-wide paths (hopefully 
>>> we won't support non standard paths in the near future).
>>>
>>> So we indeed need to modify the configure options in each spkg-install 
>>> scripts of pkgs depending on curl to have "--with-curl=`pkgconfig 
>>> --blablbabla`" or anything sensible which would tell it to either look into 
>>> $SAGE_LOCAL or in default paths.
>>> The only other way to do this without passing stuff to configure scripts 
>>> of each package is playing with LDFLAGS and CFLAGS and this has 
>>> unfortunately less chances of success than using configure scripts options, 
>>> good luck with that.
>>>
>>>
 Furthermore, that introduce the possibility of having *simultaneously* 
 some packages using  our version of curl and others using system's 
 version. 
 Ouch...

 Yes maybe.
>>> I can surely make it so that Sage gets both ATLAS and openblas installed 
>>> if I really want to and link to both of them in a random way. 
>>>
>>> A more consistent way would be to pass a flag to curl's installation 
 script telling it to fake installation or to force build. That is 
 possible, 
 but, again, not very consistent with the primitive idea of enforcing some 
 consistency.

>>> No it does not solve the issue of packages having to link to libcurl. 
>>> Unless you want to play with LDFLAGS and C[...]FLAGS rather than passing 
>>> options to configure scripts of these packages.
>>>
>> In fact you still have to deal with LDFLAGS and CPPFLAGS.
>> At least R only looks in what they define and you cannot give anything 
>> through a --with-curl= option.
>>
>> By the way it seems that Sage modifies by default LDFLAGS globally to 
>> include $SAGE_LOCAL/lib but not CPPFLAGS. 
>>
>
> Maybe we can use config.site as well:
> https://www.gnu.org/software/automake/manual/html_node/config_002esite.html 
>

We set CPATH, but I'm not sure it is enough for autotools.

-- 
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.

[sage-devel] Re: Can we depend on system's utilities and libraries ?

[Jean-Pierre Flori]

Note that gcc or pkgconfig are easier to deal with as they just need to be 
in PATH and nothing links to them or includes headers from them.

-- 
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.

[sage-devel] Re: Can we depend on system's utilities and libraries ?

[Jean-Pierre Flori]

On Wednesday, October 26, 2016 at 2:22:45 PM UTC+2, Jean-Pierre Flori wrote:
>
>
>
> On Wednesday, October 26, 2016 at 2:08:25 PM UTC+2, Emmanuel Charpentier 
> wrote:
>>
>>
>>
>> Le mercredi 26 octobre 2016 13:40:14 UTC+2, Jean-Pierre Flori a écrit :
>>>
>>> It would be great to let the user choose when to use system libraries 
>>> instead of building our own, whether its curl or gmp.
>>> A problem coming to my mind to have a simple --with-curl=[system|build] 
>>> working.
>>>
>>
>> That means, if I follow you, to have to patch each and every (candidate) 
>> package potentially using curl in order to consider this flag. Not exactly 
>> low-maintainance... 
>>
> What do we gain ?
>>
> I don't get you.
>
> The current situation is that for every package built by Sage depending on 
> any other package built by Sage, we have to tell them to look into 
> $SAGE_LOCAL for including headers and linking to libraries.
>
> I suggest to add a --with-curl=... or --with-systemwide-pkgs=... option to 
> the toplevel configure of "Sage the distribution" to tell "Sage the 
> distribution" not to build its own curl but to rely on a system wide one.
> But then we have to tell each package built by "Sage the distribution" to 
> look for its dependencies either in $SAGE_LOCAL (which is basically always 
> the case at the moment) or in standard system-wide paths (hopefully we 
> won't support non standard paths in the near future).
>
> So we indeed need to modify the configure options in each spkg-install 
> scripts of pkgs depending on curl to have "--with-curl=`pkgconfig 
> --blablbabla`" or anything sensible which would tell it to either look into 
> $SAGE_LOCAL or in default paths.
> The only other way to do this without passing stuff to configure scripts 
> of each package is playing with LDFLAGS and CFLAGS and this has 
> unfortunately less chances of success than using configure scripts options, 
> good luck with that.
>
>
>> Furthermore, that introduce the possibility of having *simultaneously* 
>> some packages using  our version of curl and others using system's version. 
>> Ouch...
>>
>> Yes maybe.
> I can surely make it so that Sage gets both ATLAS and openblas installed 
> if I really want to and link to both of them in a random way. 
>
> A more consistent way would be to pass a flag to curl's installation 
>> script telling it to fake installation or to force build. That is possible, 
>> but, again, not very consistent with the primitive idea of enforcing some 
>> consistency.
>>
> No it does not solve the issue of packages having to link to libcurl. 
> Unless you want to play with LDFLAGS and C[...]FLAGS rather than passing 
> options to configure scripts of these packages.
>
In fact you still have to deal with LDFLAGS and CPPFLAGS.
At least R only looks in what they define and you cannot give anything 
through a --with-curl= option.

By the way it seems that Sage modifies by default LDFLAGS globally to 
include $SAGE_LOCAL/lib but not CPPFLAGS. 

-- 
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.

[sage-devel] Re: Installing JupyterHub and LDAP

[Dima Pasechnik]

On Wednesday, October 26, 2016 at 10:40:50 AM UTC, Jori Mäntysalo wrote:
>
> More progress, but now I am stuck. Last time I ended on 
>
> > pip3 install jupyterhub 
> > 
> > Noticed that it used IPv6, got a headache when googling, found the 
> > instruction to put GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet" on 
> > /etc/default/grub, said update-grub and got the login prompt. 
>
> and after that 
>
> jupyterhub --no-ssl --port=80 
>
> works. Next, I did a snakeoil cert: 
>
> openssl req -newkey rsa:2048 -new -nodes -keyout key.pem -out csr.pem 
> openssl x509 -req -days 365 -in csr.pem -signkey key.pem -out server.crt 
>
> and said 
>
> jupyterhub --ssl-key=/root/key.pem --ssl-cert=/root/server.crt –port=443 
>
> and now I have https connection. Then I said 
>
> apt-get install ldap-auth-client nscd 
>
> and gave parameters, and checked with 
>
> getent passwd 
>
> that the server sees ldap users. Then I put 
>
> from ldapauthenticator import LDAPAuthenticator 
>
> c.JupyterHub.authenticator_class = 'ldapauthenticator.LDAPAuthenticator' 
> c.LDAPAuthenticator.server_address = 'ldaps://ldap.myunit.uta.fi' 
> c.LDAPAuthenticator.bind_dn_template = 
> 'uid={username},ou=People,dc=myunit,dc=uta,dc=fi' 
>
> to jupyterhub_config.py. 
>
> Now I was able to log in with my LDAP username. But it does not work, I 
> got 
>
> Couldn't set CWD to /home/staff/jm58660 ([Errno 2] No such file or 
> directory: '/home/staff/jm58660') 
>
> Couldn't set CWD to /home/staff ([Errno 2] No such file or directory: 
> '/home/staff') 
>
> /usr/local/lib/python3.5/dist-packages/IPython/paths.py:69: UserWarning: 
> IPython parent '/home/staff/jm58660' is not a writable location, using a 
> temp directory. 
>
> and so a "500 internal error". So how to tell Jupyterhub to use some kind 
> of temporary directory for ldap users? 
>
>   * * * 
>
> Some other things: Is it possible to run plain R (or GAP or...) from 
> Jupyter? Can I change worksheet type, for example test what "10/4" will 
> output as a plain Python2? 
>

you probably need to change the jupyter kernel to the one for R (which does 
exist, and is stable, I think)
resp. for GAP (does exist too, albeit still in beta, IMHO: see 
http://opendreamkit.org/activities/2016-08-03-gap-docker-jupyter/)

 

>
> Both are possible with SageNB. 
>
> -- 
> Jori Mäntysalo

-- 
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.

[sage-devel] Re: Can we depend on system's utilities and libraries ?

[Jean-Pierre Flori]

On Wednesday, October 26, 2016 at 2:58:44 PM UTC+2, Jean-Pierre Flori wrote:
>
>
>
> On Wednesday, October 26, 2016 at 2:22:45 PM UTC+2, Jean-Pierre Flori 
> wrote:
>>
>>
>>
>> On Wednesday, October 26, 2016 at 2:08:25 PM UTC+2, Emmanuel Charpentier 
>> wrote:
>>>
>>>
>>>
>>> Le mercredi 26 octobre 2016 13:40:14 UTC+2, Jean-Pierre Flori a écrit :

 It would be great to let the user choose when to use system libraries 
 instead of building our own, whether its curl or gmp.
 A problem coming to my mind to have a simple --with-curl=[system|build] 
 working.

>>>
>>> That means, if I follow you, to have to patch each and every (candidate) 
>>> package potentially using curl in order to consider this flag. Not exactly 
>>> low-maintainance... 
>>>
>> What do we gain ?
>>>
>> I don't get you.
>>
>> The current situation is that for every package built by Sage depending 
>> on any other package built by Sage, we have to tell them to look into 
>> $SAGE_LOCAL for including headers and linking to libraries.
>>
>> I suggest to add a --with-curl=... or --with-systemwide-pkgs=... option 
>> to the toplevel configure of "Sage the distribution" to tell "Sage the 
>> distribution" not to build its own curl but to rely on a system wide one.
>> But then we have to tell each package built by "Sage the distribution" to 
>> look for its dependencies either in $SAGE_LOCAL (which is basically always 
>> the case at the moment) or in standard system-wide paths (hopefully we 
>> won't support non standard paths in the near future).
>>
>> So we indeed need to modify the configure options in each spkg-install 
>> scripts of pkgs depending on curl to have "--with-curl=`pkgconfig 
>> --blablbabla`" or anything sensible which would tell it to either look into 
>> $SAGE_LOCAL or in default paths.
>> The only other way to do this without passing stuff to configure scripts 
>> of each package is playing with LDFLAGS and CFLAGS and this has 
>> unfortunately less chances of success than using configure scripts options, 
>> good luck with that.
>>
>>
>>> Furthermore, that introduce the possibility of having *simultaneously* 
>>> some packages using  our version of curl and others using system's version. 
>>> Ouch...
>>>
>>> Yes maybe.
>> I can surely make it so that Sage gets both ATLAS and openblas installed 
>> if I really want to and link to both of them in a random way. 
>>
>> A more consistent way would be to pass a flag to curl's installation 
>>> script telling it to fake installation or to force build. That is possible, 
>>> but, again, not very consistent with the primitive idea of enforcing some 
>>> consistency.
>>>
>> No it does not solve the issue of packages having to link to libcurl. 
>> Unless you want to play with LDFLAGS and C[...]FLAGS rather than passing 
>> options to configure scripts of these packages.
>>
> In fact you still have to deal with LDFLAGS and CPPFLAGS.
> At least R only looks in what they define and you cannot give anything 
> through a --with-curl= option.
>
> By the way it seems that Sage modifies by default LDFLAGS globally to 
> include $SAGE_LOCAL/lib but not CPPFLAGS. 
>

Maybe we can use config.site as well:
https://www.gnu.org/software/automake/manual/html_node/config_002esite.html 

-- 
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] Re: Installing JupyterHub and LDAP

[Luca De Feo]

I have no experience with the LDAP authenticator. It is probably best
to ask your questions on :
https://groups.google.com/forum/#!forum/jupyter

Luca



On Wed, Oct 26, 2016 at 12:40 PM, Jori Mäntysalo  wrote:
> More progress, but now I am stuck. Last time I ended on
>
>> pip3 install jupyterhub
>>
>> Noticed that it used IPv6, got a headache when googling, found the
>> instruction to put GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet" on
>> /etc/default/grub, said update-grub and got the login prompt.
>
>
> and after that
>
> jupyterhub --no-ssl --port=80
>
> works. Next, I did a snakeoil cert:
>
> openssl req -newkey rsa:2048 -new -nodes -keyout key.pem -out csr.pem
> openssl x509 -req -days 365 -in csr.pem -signkey key.pem -out server.crt
>
> and said
>
> jupyterhub --ssl-key=/root/key.pem --ssl-cert=/root/server.crt –port=443
>
> and now I have https connection. Then I said
>
> apt-get install ldap-auth-client nscd
>
> and gave parameters, and checked with
>
> getent passwd
>
> that the server sees ldap users. Then I put
>
> from ldapauthenticator import LDAPAuthenticator
>
> c.JupyterHub.authenticator_class = 'ldapauthenticator.LDAPAuthenticator'
> c.LDAPAuthenticator.server_address = 'ldaps://ldap.myunit.uta.fi'
> c.LDAPAuthenticator.bind_dn_template =
> 'uid={username},ou=People,dc=myunit,dc=uta,dc=fi'
>
> to jupyterhub_config.py.
>
> Now I was able to log in with my LDAP username. But it does not work, I got
>
> Couldn't set CWD to /home/staff/jm58660 ([Errno 2] No such file or
> directory: '/home/staff/jm58660')
>
> Couldn't set CWD to /home/staff ([Errno 2] No such file or directory:
> '/home/staff')
>
> /usr/local/lib/python3.5/dist-packages/IPython/paths.py:69: UserWarning:
> IPython parent '/home/staff/jm58660' is not a writable location, using a
> temp directory.
>
> and so a "500 internal error". So how to tell Jupyterhub to use some kind of
> temporary directory for ldap users?
>
>  * * *
>
> Some other things: Is it possible to run plain R (or GAP or...) from
> Jupyter? Can I change worksheet type, for example test what "10/4" will
> output as a plain Python2?
>
> Both are possible with SageNB.
>
> --
> Jori Mäntysalo

-- 
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] Re: Installing JupyterHub and LDAP

[Luca De Feo]

> Some other things: Is it possible to run plain R (or GAP or...) from
> Jupyter? Can I change worksheet type, for example test what "10/4" will
> output as a plain Python2?
>
> Both are possible with SageNB.

You can change the kernel via the "Kernel" menu (there are kernels for
R, GAP, PARI/GP, Python, etc.), or you can change the kernel inside a
single cell with

%%python2
print 10//4

I just tested that this works in the Jupyter notebook shipped with
Sage, %%python3 breaks, though.

Luca

-- 
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.

[sage-devel] Re: Can we depend on system's utilities and libraries ?

[Jean-Pierre Flori]

As far as dependency tracking is concerned we could use the 
"need_to_install" magic in configure.ac.

-- 
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.

[sage-devel] Re: Can we depend on system's utilities and libraries ?

[Emmanuel Charpentier]

Le mercredi 26 octobre 2016 13:40:14 UTC+2, Jean-Pierre Flori a écrit :
>
> It would be great to let the user choose when to use system libraries 
> instead of building our own, whether its curl or gmp.
> A problem coming to my mind to have a simple --with-curl=[system|build] 
> working.
>

That means, if I follow you, to have to patch each and every (candidate) 
package potentially using curl in order to consider this flag. Not exactly 
low-maintainance... What do we gain ?

Furthermore, that introduce the possibility of having *simultaneously* some 
packages using  our version of curl and others using system's version. 
Ouch...

A more consistent way would be to pass a flag to curl's installation script 
telling it to fake installation or to force build. That is possible, but, 
again, not very consistent with the primitive idea of enforcing some 
consistency.
 

> For packages that will still be built and use curl, what we currently do, 
> at least for packages using autotools or standard configure/make/make 
> install strategies, is that we pass --with-curl=$SAGE_LOCAL or something 
> like that.
> Now if we allow curl to be either in $SAGE_LOCAL or in a sytem-wide 
> default path we cannot go this way.
>
> Using --with-curl=`pkgconfig --lib curl` (or whatever pkgconfig syntax is) 
> might do the trick for libs providing pkgconfig files (once we make sure 
> Sage or systemwide pkgconfig looks first in $SAGE_LOCAL, then in systemwide 
> dirs).
>
> Another solution is to globally tweak CFLAGS and LDFLAGS but that will be 
> hell.
>
> How does sage-on-gentoo deal with this?
>

-- 
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.

[sage-devel] Re: Can we depend on system's utilities and libraries ?

[Jean-Pierre Flori]

And i guess sage-on-gentoo just puts everything into standard paths.

-- 
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.

[sage-devel] Re: Can we depend on system's utilities and libraries ?

[Jean-Pierre Flori]

On Wednesday, October 26, 2016 at 2:08:25 PM UTC+2, Emmanuel Charpentier 
wrote:
>
>
>
> Le mercredi 26 octobre 2016 13:40:14 UTC+2, Jean-Pierre Flori a écrit :
>>
>> It would be great to let the user choose when to use system libraries 
>> instead of building our own, whether its curl or gmp.
>> A problem coming to my mind to have a simple --with-curl=[system|build] 
>> working.
>>
>
> That means, if I follow you, to have to patch each and every (candidate) 
> package potentially using curl in order to consider this flag. Not exactly 
> low-maintainance... 
>
What do we gain ?
>
I don't get you.

The current situation is that for every package built by Sage depending on 
any other package built by Sage, we have to tell them to look into 
$SAGE_LOCAL for including headers and linking to libraries.

I suggest to add a --with-curl=... or --with-systemwide-pkgs=... option to 
the toplevel configure of "Sage the distribution" to tell "Sage the 
distribution" not to build its own curl but to rely on a system wide one.
But then we have to tell each package built by "Sage the distribution" to 
look for its dependencies either in $SAGE_LOCAL (which is basically always 
the case at the moment) or in standard system-wide paths (hopefully we 
won't support non standard paths in the near future).

So we indeed need to modify the configure options in each spkg-install 
scripts of pkgs depending on curl to have "--with-curl=`pkgconfig 
--blablbabla`" or anything sensible which would tell it to either look into 
$SAGE_LOCAL or in default paths.
The only other way to do this without passing stuff to configure scripts of 
each package is playing with LDFLAGS and CFLAGS and this has unfortunately 
less chances of success than using configure scripts options, good luck 
with that.


> Furthermore, that introduce the possibility of having *simultaneously* 
> some packages using  our version of curl and others using system's version. 
> Ouch...
>
> Yes maybe.
I can surely make it so that Sage gets both ATLAS and openblas installed if 
I really want to and link to both of them in a random way. 

A more consistent way would be to pass a flag to curl's installation script 
> telling it to fake installation or to force build. That is possible, but, 
> again, not very consistent with the primitive idea of enforcing some 
> consistency.
>
No it does not solve the issue of packages having to link to libcurl. 
Unless you want to play with LDFLAGS and C[...]FLAGS rather than passing 
options to configure scripts of these packages.

-- 
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.

[sage-devel] Re: add curl as a standard package

[Volker Braun]

On Wednesday, October 26, 2016 at 2:40:42 AM UTC-4, Emmanuel Charpentier 
wrote:
>
> This issue is *distinct* from the one I'm trying to solve (iL e. satisfy 
> R's prerequisites). Should't you open a relevant ticket ? 
>

Its not really a distinct issue, its a general caveat of compiling your own 
curl. And even if we (and/or R) don't use curl to download over ssl today, 
this will surely change in the future.

-- 
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.

[sage-devel] Re: add curl as a standard package

[Jean-Pierre Flori]

On Wednesday, October 26, 2016 at 3:45:02 PM UTC+2, Volker Braun wrote:
>
> On Wednesday, October 26, 2016 at 2:40:42 AM UTC-4, Emmanuel Charpentier 
> wrote:
>>
>> This issue is *distinct* from the one I'm trying to solve (iL e. satisfy 
>> R's prerequisites). Should't you open a relevant ticket ? 
>>
>
> Its not really a distinct issue, its a general caveat of compiling your 
> own curl. And even if we (and/or R) don't use curl to download over ssl 
> today, this will surely change in the future.
>
Hum, it seems to me that R wants curl with https support, look at
https://svn.r-project.org/R/trunk/m4/R.m4 

"libcurl >= 7.28.0 library and headers are required with support for https"


-- 
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] add curl as a standard package

[John H Palmieri]

On Tuesday, October 25, 2016 at 11:35:15 PM UTC-7, Emmanuel Charpentier 
wrote:
>
>
>
> Le mercredi 26 octobre 2016 00:42:01 UTC+2, John H Palmieri a écrit :
>>
>> I have no opinion on whether this approach is on the whole a good idea, 
>> but I will point out that "which curl" is not as portable as "command -v 
>> curl". We had an issue a while ago with "which" not behaving properly on 
>> some platform -- maybe on Solaris "which blah" had a return status of 0 
>> even if "blah" was not present? I forget. 
>>
>
> Note that we don't use the return status, but the path expansion. I've no 
> idea about the portability of both ; I note that which is a standard 
> binary, whereas command is internal to bash. Pick your portability poison...
>

I don't even remember if the return status was the issue. I would also 
point out that according to the web page 
http://pubs.opengroup.org/onlinepubs/9699919799/, "command" is listed as a 
standard shell utility, but not "which".

-- 
John

-- 
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] add curl as a standard package

[Jean-Pierre Flori]

There is a curl-config utility.

-- 
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.

[sage-devel] Re: Can we depend on system's utilities and libraries ?

[Jean-Pierre Flori]

Sure. What you uncovered here is larger than R.

-- 
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.