The short answer is that Sage is designed for (among others) research mathematicians, who may not have the interest or inclination to learn how to install lots of system packages. So from the beginning it included as many components as possible. Years ago the presence of MacPorts and other similar systems would actually break the Sage build process, so the build process may attempt to disable them. Whether it tried to disable them, for a long time Sage refused to use any system packages and just built everything itself (with a few exceptions, like gcc).
This has been changing recently, and now Sage can use many system packages. This is restricted to systems (OS + package manager) used by Sage developers, and apparently no developer uses MacPorts, or at least not enough to spend time getting Sage to work with it. Homebrew is pretty well integrated with the Sage build process. On Wednesday, December 23, 2020 at 6:11:32 AM UTC-8 u...@ll.mit.edu wrote: > I looked into build/pgks/* (1.5 GB) and it appears that Sage is trying to > be a package manager, in addition to what people probably want it for. > > I guess at version 9.2 it's rather late to ask why it isn't good enough to > just list in the README a set of packages that Sage requires to run, and > have a minimal config that would check for their presence at install time? > Letting user to worry about, e.g., where and how to install OpenSSL-1.1.x > or python38? > -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-support/06787647-8d63-4e0b-912b-3ddefc516833n%40googlegroups.com.
