Re: [sage-packaging] Re: [sage-devel] Brainstorming about Sage dependencies from system packages

[Erik Bray]

On Sat, May 27, 2017 at 1:51 PM, Isuru Fernando  wrote:
> On Sat, May 27, 2017 at 4:46 PM, Erik Bray  wrote:
>>
>> On May 27, 2017 11:13 AM, "Volker Braun"  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 into
>> separate binary achive that then gets installed.
>>
>>
>> Can I just rein things back in here for a sec? I shouldn't have posted
>> this on Friday--I don't want to get into any detailed discussions until I'm
>> back at work on Monday :)
>>
>> I just wanted to say, that the whole point of what I'm proposing is that
>> it's *not* a major change. I agree in principle with everything you're
>> saying and would be happy to talk about bigger changes in a separate
>> context.
>>
>> All I'm proposing are some very *minor* changes that change little about
>> how Sage is currently worked on, while still being a quality of life
>> improvement, in a way.
>
>
> If you can do this, then it'll be simple to use conda. All the dependencies
> are in `conda-forge` for linux (osx needs only a cython upgrade), so it's a
> matter of telling the build system to use the conda packages as system ones.

Hi Isuru,

Exactly! With these changes, building Sage in any environment is the
same as before.  But if building in a conda environment (just as an
example) this is a way to get it to use the conda
packages--selectively if needed.  It can also be useful for finding
out what packages are missing, or don't quite meet Sage's needs.

If we wanted to go further one day and replace Sage's old build system
entirely with something based on Conda that's a good thing to talk
about (as we already have before), but this is a small stepping stone
to that.

Erik


>> In other words, it's something I can do now with maybe a few days of work
>> instead of a major overhaul of everything. So I'd rather this thread focus
>> on the details of those minor changes than any big ideas that may or may not
>> go anywhere.
>>
>>
>>
>> * Going back in the git history then involves no recompilation, only
>> re-extracting the cached binaries.
>> * You can decide on a per-package level if you want to (re-)compile it or
>> use a binary package
>> * The whole thing can just be published as a conda channel, just run
>> "conda install --channel https://sagemath.org sage"
>> * Incremental binary updates for free
>> * We could build on conda (-forge) instead of maintaining our own patch,
>> python, ... packages.
>> * A conda build recipe is just a better version of how we currently define
>> packages (spkg-install -> build.sh, metadata in meta.yaml instead of
>> scattered into multiple files)
>>
>>
>>
>>
>> On Friday, May 26, 2017 at 11:49:03 PM UTC+2, William wrote:
>>>
>>> On Fri, May 26, 2017 at 6:01 AM, Erik Bray  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
>>> > unusual, but Sage does nearly all (even down the gcc, in certain
>>> > cases).  I've learned a lot of the history to this over the past year,
>>> > and agree that most of the time this has been done with good reasons.
>>> >
>>> > For example, I can't think of any other software that forces me to
>>> > build its own copy of ncurses just to build/install it.  This was
>>>
>>> Maybe Anaconda?
>>>
>>> https://anaconda.org/anaconda/ncurses
>>>
>>> The approach in Sage is indeed very rare, but it's interesting that
>>> another similar situation is with another big Python computing stack
>>> (Anaconda), which was developed independently.  In any case, it's
>>> worth mentioning Anaconda in the proposal.
>>>
>>>  -- William
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sage-packaging" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sage-packaging+unsubscr...@googlegroups.com.
>> To post to this group, send email to sage-packag...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/sage-packaging/a9a640d6-6fec-40b0-b8f2-249c3dae10db%40googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sage-packaging" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sage-packaging+unsubscr...@googlegroups.com.
>> To post to this group, send email to sage-packag...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/sage-packaging/CAOTD34aUu25iha%3DnQStKWZWLrHgT_TU3KpNiyqZEk1H9yN-fNA%40mail.gmail.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received t

Re: [sage-packaging] Re: [sage-devel] Brainstorming about Sage dependencies from system packages

[Felix Salfelder]

On Sat, May 27, 2017 at 01:16:39PM +0200, Erik Bray wrote:
> All I'm proposing are some very *minor* changes that change little about
> how Sage is currently worked on, while still being a quality of life
> improvement, in a way.

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 all bikeshed).

> In other words, it's something I can do now with maybe a few days of work
> instead of a major overhaul of everything. So I'd rather this thread focus
> on the details of those minor changes than any big ideas that may or may
> not go anywhere.

the place where I would start today is just the blacklists. i.e. have
toplevel configure flags that allow telling sage-the-distribution not to
build spkgs. rather pretend they are "installed" (into $SAGE_LOCAL,
as usual) to all other parts.

something similar to
$ ./configure --disable-patch --disable-ncurses

will then effectively fallback to system packages without much more
work. note how 4 years back, even the use of PATH was highly
controversial. i reckon the situation has improved.

the blacklist method will enable anyone (i am thinking of power-users
and distributors, conda fans, or myself), to try, and send patches...
some of them will be needed.

i see the point of having all sorts of magic to determine whether or not
a system package substitutes an spkg. (and i partly did some of that kind
myself). i do now consider that pointless, way too much work. imo,
nowadays, functionality checks should be on package level, and a
transition path close to

- provide blacklists
- switch to system packages, one by one, fix the remaining
- eventually reach "./configure --disable-all --enable-sagelib"
- use standalone (vanilla) sagelib on gentoo, conda, debian, etcpp
- ditch sage-the-distribution for (something similar to) conda

seems feasible. at the end, it does not matter much, what spkg -i
 might have done during the transition. keep
it simple, print a warning "not supported", and exit 1.

regards
felix

-- 
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-packaging] Re: [sage-devel] Brainstorming about Sage dependencies from system packages

[Isuru Fernando]

On Sat, May 27, 2017 at 4:46 PM, Erik Bray  wrote:

> On May 27, 2017 11:13 AM, "Volker Braun"  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 into
> separate binary achive that then gets installed.
>
>
> Can I just rein things back in here for a sec? I shouldn't have posted
> this on Friday--I don't want to get into any detailed discussions until I'm
> back at work on Monday :)
>
> I just wanted to say, that the whole point of what I'm proposing is that
> it's *not* a major change. I agree in principle with everything you're
> saying and would be happy to talk about bigger changes in a separate
> context.
>
> All I'm proposing are some very *minor* changes that change little about
> how Sage is currently worked on, while still being a quality of life
> improvement, in a way.
>

If you can do this, then it'll be simple to use conda. All the dependencies
are in `conda-forge` for linux (osx needs only a cython upgrade), so it's a
matter of telling the build system to use the conda packages as system ones.

Isuru Fernando


>
> In other words, it's something I can do now with maybe a few days of work
> instead of a major overhaul of everything. So I'd rather this thread focus
> on the details of those minor changes than any big ideas that may or may
> not go anywhere.
>
>
>
> * Going back in the git history then involves no recompilation, only
> re-extracting the cached binaries.
> * You can decide on a per-package level if you want to (re-)compile it or
> use a binary package
> * The whole thing can just be published as a conda channel, just run
> "conda install --channel https://sagemath.org sage"
> * Incremental binary updates for free
> * We could build on conda (-forge) instead of maintaining our own patch,
> python, ... packages.
> * A conda build recipe is just a better version of how we currently define
> packages (spkg-install -> build.sh, metadata in meta.yaml instead of
> scattered into multiple files)
>
>
>
>
> On Friday, May 26, 2017 at 11:49:03 PM UTC+2, William wrote:
>
>> On Fri, May 26, 2017 at 6:01 AM, Erik Bray  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
>> > unusual, but Sage does nearly all (even down the gcc, in certain
>> > cases).  I've learned a lot of the history to this over the past year,
>> > and agree that most of the time this has been done with good reasons.
>> >
>> > For example, I can't think of any other software that forces me to
>> > build its own copy of ncurses just to build/install it.  This was
>>
>> Maybe Anaconda?
>>
>> https://anaconda.org/anaconda/ncurses
>>
>> The approach in Sage is indeed very rare, but it's interesting that
>> another similar situation is with another big Python computing stack
>> (Anaconda), which was developed independently.  In any case, it's
>> worth mentioning Anaconda in the proposal.
>>
>>  -- William
>>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-packaging" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-packaging+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-packag...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/sage-packaging/a9a640d6-6fec-40b0-b8f2-249c3dae10db%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-packaging" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-packaging+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-packag...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/sage-packaging/CAOTD34aUu25iha%3DnQStKWZWLrHgT_
> TU3KpNiyqZEk1H9yN-fNA%40mail.gmail.com
> 
> .
>
> 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

Re: [sage-devel] Brainstorming about Sage dependencies from system packages

[Erik Bray]

On May 27, 2017 11:32 AM, "Jeroen Demeyer"  wrote:

Otherwise it sets `$(inst_)` 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 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 -i PKGNAME
will *not* install the Sage package since the "spkg" is satisfied by the
system package.

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'll respond in more detail later but I agree with you completely here.


By default, all packages would be installed from the sage-dist source
> as is the case now.
>

I wonder why you propose this. The reason why we check for gcc for example
is because we want to avoid building the Sage package if we can. If you go
to the trouble of adding a check for system packages, the default should be
to *not* install the Sage package if the system package works.


This is the kind of detail that I think is arguable and why I wanted to
write a long message explaining it :)

The reason I proposed this was just to change as little as possible about
the current behavior (something like GCC would be a special case). Another
reason is that checking for every package would make configure take a lot
longer, though I do think the results of those checks should be cached, so
maybe most of the time it would not be too bad.

I'd be fine with going either way. The --with-system-all option would
basically be the behavior of checking for every package. The question is
whether it should error if a package isn't found, or just build the
sage-dist package. (Or there can be a flag for that behavior in which case
the question is what the default should be).


Apart from these two points, I totally agree with your post. Now to find a
volunteer to implement all that :-)


I'm volunteering! I just wanted to run the idea by people in detail first.


Erik

-- 
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-packaging] Re: [sage-devel] Brainstorming about Sage dependencies from system packages

[Erik Bray]

On May 27, 2017 11:13 AM, "Volker Braun"  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 into
separate binary achive that then gets installed.


Can I just rein things back in here for a sec? I shouldn't have posted this
on Friday--I don't want to get into any detailed discussions until I'm back
at work on Monday :)

I just wanted to say, that the whole point of what I'm proposing is that
it's *not* a major change. I agree in principle with everything you're
saying and would be happy to talk about bigger changes in a separate
context.

All I'm proposing are some very *minor* changes that change little about
how Sage is currently worked on, while still being a quality of life
improvement, in a way.

In other words, it's something I can do now with maybe a few days of work
instead of a major overhaul of everything. So I'd rather this thread focus
on the details of those minor changes than any big ideas that may or may
not go anywhere.



* Going back in the git history then involves no recompilation, only
re-extracting the cached binaries.
* You can decide on a per-package level if you want to (re-)compile it or
use a binary package
* The whole thing can just be published as a conda channel, just run "conda
install --channel https://sagemath.org sage"
* Incremental binary updates for free
* We could build on conda (-forge) instead of maintaining our own patch,
python, ... packages.
* A conda build recipe is just a better version of how we currently define
packages (spkg-install -> build.sh, metadata in meta.yaml instead of
scattered into multiple files)




On Friday, May 26, 2017 at 11:49:03 PM UTC+2, William wrote:

> On Fri, May 26, 2017 at 6:01 AM, Erik Bray  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
> > unusual, but Sage does nearly all (even down the gcc, in certain
> > cases).  I've learned a lot of the history to this over the past year,
> > and agree that most of the time this has been done with good reasons.
> >
> > For example, I can't think of any other software that forces me to
> > build its own copy of ncurses just to build/install it.  This was
>
> Maybe Anaconda?
>
> https://anaconda.org/anaconda/ncurses
>
> The approach in Sage is indeed very rare, but it's interesting that
> another similar situation is with another big Python computing stack
> (Anaconda), which was developed independently.  In any case, it's
> worth mentioning Anaconda in the proposal.
>
>  -- William
>
-- 
You received this message because you are subscribed to the Google Groups
"sage-packaging" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to sage-packaging+unsubscr...@googlegroups.com.
To post to this group, send email to sage-packag...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/sage-packaging/a9a640d6-6fec-40b0-b8f2-249c3dae10db%40googlegroups.com

.

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] Brainstorming about Sage dependencies from system packages

[Jeroen Demeyer]

Otherwise it sets `$(inst_)` 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 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 -i 
PKGNAME will *not* install the Sage package since the "spkg" is 
satisfied by the system package.


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.



By default, all packages would be installed from the sage-dist source
as is the case now.


I wonder why you propose this. The reason why we check for gcc for 
example is because we want to avoid building the Sage package if we can. 
If you go to the trouble of adding a check for system packages, the 
default should be to *not* install the Sage package if the system 
package works.


Apart from these two points, I totally agree with your post. Now to find 
a volunteer to implement all that :-)



Jeroen.

--
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-packaging] Re: [sage-devel] Brainstorming about Sage dependencies from system packages

[Isuru Fernando]

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  wrote:

> On May 26, 2017 23:49, "William Stein"  wrote:
>
> On Fri, May 26, 2017 at 6:01 AM, Erik Bray  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
> > unusual, but Sage does nearly all (even down the gcc, in certain
> > cases).  I've learned a lot of the history to this over the past year,
> > and agree that most of the time this has been done with good reasons.
> >
> > For example, I can't think of any other software that forces me to
> > build its own copy of ncurses just to build/install it.  This was
>
> Maybe Anaconda?
>
> https://anaconda.org/anaconda/ncurses
>
> The approach in Sage is indeed very rare, but it's interesting that
> another similar situation is with another big Python computing stack
> (Anaconda), which was developed independently.  In any case, it's
> worth mentioning Anaconda in the proposal.
>
>
> I didn't really think of Anaconda since it's not a single software
> application like Sage. As a self-contained packing system of course most
> packages included in Anaconda are of this nature. But of course Anaconda
> doesn't necessarily distribute *everything* it needs to work either.
> ncurses sort of makes sense to include since a buggy ncurses can be a real
> deal-breaker for UX.
>
> My favorite bugbear in Sage is its inclusion of patch. I wince every time
> I start a fresh build of Sage and it starts compiling patch. I'm sure there
> was a good reason for it, and it's very minor in the grand scheme of
> things, but I think points quite obvious for a need to have better control
> over what we can use from the system.
>
> Best,
> Erik
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-packaging" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-packaging+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-packag...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/sage-packaging/CAOTD34b53fuFHpPNXpMVuVj2R9m-
> YFAbg%3DjqF1QPDNveycz9Ag%40mail.gmail.com
> 
> .
>
> 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] Brainstorming about Sage dependencies from system packages

[Volker Braun]

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 git history then involves no recompilation, only 
re-extracting the cached binaries.
* You can decide on a per-package level if you want to (re-)compile it or 
use a binary package
* The whole thing can just be published as a conda channel, just run "conda 
install --channel https://sagemath.org sage"
* Incremental binary updates for free
* We could build on conda (-forge) instead of maintaining our own patch, 
python, ... packages.
* A conda build recipe is just a better version of how we currently define 
packages (spkg-install -> build.sh, metadata in meta.yaml instead of 
scattered into multiple files)




On Friday, May 26, 2017 at 11:49:03 PM UTC+2, William wrote:
>
> On Fri, May 26, 2017 at 6:01 AM, Erik Bray  > 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 
> > unusual, but Sage does nearly all (even down the gcc, in certain 
> > cases).  I've learned a lot of the history to this over the past year, 
> > and agree that most of the time this has been done with good reasons. 
> > 
> > For example, I can't think of any other software that forces me to 
> > build its own copy of ncurses just to build/install it.  This was 
>
> Maybe Anaconda? 
>
> https://anaconda.org/anaconda/ncurses 
>
> The approach in Sage is indeed very rare, but it's interesting that 
> another similar situation is with another big Python computing stack 
> (Anaconda), which was developed independently.  In any case, it's 
> worth mentioning Anaconda in the proposal. 
>
>  -- William 
>

-- 
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-packaging] Re: [sage-devel] Brainstorming about Sage dependencies from system packages

[Erik Bray]

On May 26, 2017 23:49, "William Stein"  wrote:

On Fri, May 26, 2017 at 6:01 AM, Erik Bray  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
> unusual, but Sage does nearly all (even down the gcc, in certain
> cases).  I've learned a lot of the history to this over the past year,
> and agree that most of the time this has been done with good reasons.
>
> For example, I can't think of any other software that forces me to
> build its own copy of ncurses just to build/install it.  This was

Maybe Anaconda?

https://anaconda.org/anaconda/ncurses

The approach in Sage is indeed very rare, but it's interesting that
another similar situation is with another big Python computing stack
(Anaconda), which was developed independently.  In any case, it's
worth mentioning Anaconda in the proposal.


I didn't really think of Anaconda since it's not a single software
application like Sage. As a self-contained packing system of course most
packages included in Anaconda are of this nature. But of course Anaconda
doesn't necessarily distribute *everything* it needs to work either.
ncurses sort of makes sense to include since a buggy ncurses can be a real
deal-breaker for UX.

My favorite bugbear in Sage is its inclusion of patch. I wince every time I
start a fresh build of Sage and it starts compiling patch. I'm sure there
was a good reason for it, and it's very minor in the grand scheme of
things, but I think points quite obvious for a need to have better control
over what we can use from the system.

Best,
Erik

-- 
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] Brainstorming about Sage dependencies from system packages

[Dima Pasechnik]

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 typically have 
to rebuilt to ensure this.

Dima

-- 
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] Brainstorming about Sage dependencies from system packages

[William Stein]

On Fri, May 26, 2017 at 6:01 AM, Erik Bray  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
> unusual, but Sage does nearly all (even down the gcc, in certain
> cases).  I've learned a lot of the history to this over the past year,
> and agree that most of the time this has been done with good reasons.
>
> For example, I can't think of any other software that forces me to
> build its own copy of ncurses just to build/install it.  This was

Maybe Anaconda?

https://anaconda.org/anaconda/ncurses

The approach in Sage is indeed very rare, but it's interesting that
another similar situation is with another big Python computing stack
(Anaconda), which was developed independently.  In any case, it's
worth mentioning Anaconda in the proposal.

 -- William

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