sage-devel
https://groups.google.com/d/forum/sage-devel
This email list is for discussion of Sage (<a href="http://www.sagemath.org">www.sagemath.org</a>) development issues. This list usually has heavy traffic.enRe: [sage-packaging] Re: [sage-devel] Brainstorming about Sage dependencies from system packages
https://groups.google.com/d/msg/sage-devel/nTwhCV89FXE/dfdUfNoJBwAJ
Hi Erik. that's great news. and it sounds like the way to go, particulary in contrast to what i tried four years ago. (TL;DR; that was a demo of a modified sagelib that worked on a modified sage-the-distribution, as well as on debian -- i made choices, likely too pragmatic, and it went allhttps://groups.google.com/d/topic/sage-devel/nTwhCV89FXE
Felix SalfelderSat, 27 May 2017 13:53:48 UTCRe: Brainstorming about Sage dependencies from system packages
https://groups.google.com/d/msg/sage-devel/nTwhCV89FXE/2k0HOqgGBwAJ
Hi, On 2017-05-27, Jeroen Demeyer <jdem...@cage.ugent.be> wrote: > Personally, I find it more intuitive if "sage -i PKGNAME" would > unconditionally install the Sage package PKGNAME, even if PKGNAME was > detected as system package. I find it more intuitive if "sage -f PKGNAME" would installhttps://groups.google.com/d/topic/sage-devel/nTwhCV89FXE
Simon KingSat, 27 May 2017 12:55:13 UTCRe: [sage-packaging] Re: [sage-devel] Brainstorming about Sage dependencies from system packages
https://groups.google.com/d/msg/sage-devel/nTwhCV89FXE/_1bmBDUDBwAJ
On Sat, May 27, 2017 at 4:46 PM, Erik Bray <erik....@gmail.com> wrote: > On May 27, 2017 11:13 AM, "Volker Braun" <vbrau...@gmail.com> wrote: > > In fact, if we were to do some major changes to the build system we should > consider building on top of conda. In particular, we shouldn't just crap >https://groups.google.com/d/topic/sage-devel/nTwhCV89FXE
Isuru FernandoSat, 27 May 2017 11:52:00 UTCRe: [sage-devel] Brainstorming about Sage dependencies from system packages
https://groups.google.com/d/msg/sage-devel/nTwhCV89FXE/j5sXa9MBBwAJ
On May 27, 2017 11:32 AM, "Jeroen Demeyer" <jdem...@cage.ugent.be> wrote: Otherwise it sets `$(inst_<spkg>)` to a > dummy file that always exists (this way any dependencies for that > package are still satisfied, but the spkg is never actually > built/installed). > Let me mention *why* I came uphttps://groups.google.com/d/topic/sage-devel/nTwhCV89FXE
Erik BraySat, 27 May 2017 11:26:41 UTCRe: [sage-packaging] Re: [sage-devel] Brainstorming about Sage dependencies from system packages
https://groups.google.com/d/msg/sage-devel/nTwhCV89FXE/qhbD_UcBBwAJ
On May 27, 2017 11:13 AM, "Volker Braun" <vbrau...@gmail.com> wrote: In fact, if we were to do some major changes to the build system we should consider building on top of conda. In particular, we shouldn't just crap arbitrary files into $SAGE_LOCAL during build, but turn each package intohttps://groups.google.com/d/topic/sage-devel/nTwhCV89FXE
Erik BraySat, 27 May 2017 11:16:42 UTCRe: [sage-devel] Brainstorming about Sage dependencies from system packages
https://groups.google.com/d/msg/sage-devel/nTwhCV89FXE/lFgVQp_7BgAJ
Let me mention *why* I came up with this dummy file: even if configure detects that a Sage package is not needed, it can still be explicitly installed by sage -i PKGNAME # This is essentially the same as "make PKGNAME" If I understand your proposal, if a system package is used, sage -ihttps://groups.google.com/d/topic/sage-devel/nTwhCV89FXE
Jeroen DemeyerSat, 27 May 2017 09:33:00 UTCRe: [sage-packaging] Re: [sage-devel] Brainstorming about Sage dependencies from system packages
https://groups.google.com/d/msg/sage-devel/nTwhCV89FXE/LQbPWJv6BgAJ
Have a look at spack as well, which is a package-manager. Although it's not a single software application, it uses system packages when specified to build a package. http://spack.readthedocs.io/en/latest/build_settings.html Isuru Fernando On Sat, May 27, 2017 at 1:19 PM, Erik Bray <erik....@gmahttps://groups.google.com/d/topic/sage-devel/nTwhCV89FXE
Isuru FernandoSat, 27 May 2017 09:14:24 UTCRe: [sage-devel] Brainstorming about Sage dependencies from system packages
https://groups.google.com/d/msg/sage-devel/nTwhCV89FXE/I5DdN5OlBwAJ
In fact, if we were to do some major changes to the build system we should consider building on top of conda. In particular, we shouldn't just crap arbitrary files into $SAGE_LOCAL during build, but turn each package into separate binary achive that then gets installed. * Going back in the githttps://groups.google.com/d/topic/sage-devel/nTwhCV89FXE
Volker BraunSat, 27 May 2017 09:13:04 UTCRe: [sage-packaging] Re: [sage-devel] Brainstorming about Sage dependencies from system packages
https://groups.google.com/d/msg/sage-devel/nTwhCV89FXE/Mfxxhvn1BgAJ
On May 26, 2017 23:49, "William Stein" <wst...@gmail.com> wrote: On Fri, May 26, 2017 at 6:01 AM, Erik Bray <erik....@gmail.com> wrote: [...] > The extent and scope to which Sage "vendors" its dependencies, in the > form of what some call "sage-the-distribution", is *not* particularly > normal inhttps://groups.google.com/d/topic/sage-devel/nTwhCV89FXE
Erik BraySat, 27 May 2017 07:49:31 UTCRe: algebraic number package?
https://groups.google.com/d/msg/sage-devel/3cSPt18Fv7Y/rhd1MOKbBwAJ
Great news!https://groups.google.com/d/topic/sage-devel/3cSPt18Fv7Y
Ralf StephanSat, 27 May 2017 06:15:28 UTCRe: [sage-devel] Brainstorming about Sage dependencies from system packages
https://groups.google.com/d/msg/sage-devel/nTwhCV89FXE/zFsfrmubBwAJ
Another system that takes the Sage-like "distribution" approach, and is worthwhile to have a look to see how they package things, is Macaulay2. However, they have a serious technical reason for such an approach, as they need compatibility with Boehm GC, and many libraries they need typicallyhttps://groups.google.com/d/topic/sage-devel/nTwhCV89FXE
Dima PasechnikSat, 27 May 2017 06:06:59 UTCRe: [sage-devel] Brainstorming about Sage dependencies from system packages
https://groups.google.com/d/msg/sage-devel/nTwhCV89FXE/ACY5MDXVBgAJ
On Fri, May 26, 2017 at 6:01 AM, Erik Bray <erik....@gmail.com> wrote: [...] > The extent and scope to which Sage "vendors" its dependencies, in the > form of what some call "sage-the-distribution", is *not* particularly > normal in the open source world. Vendoring *some* dependencies is not >https://groups.google.com/d/topic/sage-devel/nTwhCV89FXE
WilliamFri, 26 May 2017 21:49:03 UTCRe: algebraic number package?
https://groups.google.com/d/msg/sage-devel/3cSPt18Fv7Y/rCOztG5tBwAJ
There are immediate plans to implement embedded number fields and qqbar in Flint/Antic (https://github.com/wbhart/antic). In fact, there will be a workshop and coding sprint in Kaiserslautern, 31 July - 4 August partially dedicated to this topic. The workshop hasn't been formally announced yet,https://groups.google.com/d/topic/sage-devel/3cSPt18Fv7Y
Fredrik JohanssonFri, 26 May 2017 16:04:15 UTCRe: python3 : help needed
https://groups.google.com/d/msg/sage-devel/FqR-37Fu3tY/unG_CyFsBwAJ
Ah, that would explain it. Data point on naming: on my fedora25, there are /usr/bin/ipython, /usr/bin/ipython2, /usr/bin/python3 (each separate files). ipython and ipython3 are identical. The ipython2 might be a historical remnant, though. For Python, there are /usr/bin/python2.7, /usr/bin/pythhttps://groups.google.com/d/topic/sage-devel/FqR-37Fu3tY
Nils BruinFri, 26 May 2017 15:40:22 UTCRe: python3 : help needed
https://groups.google.com/d/msg/sage-devel/FqR-37Fu3tY/P7i5rYppBwAJ
Then I would say, if SAGE_PYTHON3=yes, make a symlink python -> python3 (in the ugly_py3 style). > In the ugly_py3 style, it's just a good idea to equip local/bin/ipython > with something that allows it to run python3 (so that sage -ipython works > on a py3 build). Otherwise, there should behttps://groups.google.com/d/topic/sage-devel/FqR-37Fu3tY
John H PalmieriFri, 26 May 2017 14:52:57 UTC