Provide a fuller "dev" version that can compile

[slel]

Would it be possible to provide a fuller "dev" version that can compile?

That would allow installing certain extra packages that require build tools.

Some reports from users who want to install extra packages:

• sage-support discussion: sage -i gap_packages
• Ask Sage question 57450: sage -i pynormaliz

[slel]

Alternatively, document how to make the Sage macOS app
use another Sage installation (like Gap-dot-app does).

Users who need build capability could build Sage from source,
or install fuller binaries from the Sage download site, and then
point the Sage macOS app to that more capable installation.

[NathanDunfield]

I believe no current SageMath binary distribution supports sage -i, see the discussion here. So that situation would need to be rectified "upstream" first.

[culler]

The target user for this binary distribution is a person who does not want to or does not know how to build sage from source. A user who is happy building sage from source has no need for the app and can build any additional packages that might be desired.

To keep the size of the release manageable, the SageMath app removes most of
the build environment that is created when building sage, or included in the "expert" binary distribution. Also, to avoid invalidating the code signature, the current app does not install anything, not even byte code, within the app bundle. Packages installed with pip and byte code files get written into the user's ~/.sage directory.

Installation of packages with pip does work fine, however. For example it is easy to install SnapPy within the SageMath app by running the magic command %pip install snappy.

My suggestion, for something like the gap kbmag package would be to bundle that package as a wheel that can be installed with pip. Is there some reason why the sage process does not want to make additional packages like that available as wheels?

[NathanDunfield]

My suggestion, for something like the gap kbmag package would be to bundle that package as a wheel that can be installed with pip. Is there some reason why the sage process does not want to make additional packages like that available as wheels?

Not sure about providing wheels, but my understanding is that a current Sage goal is to replace as many of the optional Sage packages with pip installable ones as possible. How that would work with kbmag I don't know (since presumably it installs things into $SAGE_LOCAL/share/gap) but regardless that's beyond the scope of the Sage_macOS project. Until sage -i blah works in some context other than a completely-built-from-source Sage, it's premature to consider supporting it here.

[slel]

Today I helped someone install SageMath 9.3 using macOS binaries
(on a Mac with Apple's command-line tools for developers installed)
and running sage -i gap_packages worked.

I thought it worked for Sage from Linux binaries too, and was
only a problem for Sage installed via package managers
such as Arch Linux, Conda, Debian, Fedora, Gentoo, etc.

But the discussion Nathan links to does mention problems with
Sage installed via Linux binaries or the Sage-Windows installer.

Thanks for the discussion and suggestions.

[NathanDunfield]

It's possible that 9.3 is an improvement over other recent versions. Out of curiosity, I got the current binary for Ubuntu 20.04 and tried sage -i gap_packages. It seemed to build the gap_packages OK, but then started rebuilding openssl, python, etc. Compile failed for python for reasons I didn't investigate. That's another common issue with sage -i: it effectively triggers a complete rebuild of some large portion of Sage itself, taking a hour or more. Another reason for the indented move to more pip-based packages.