I'd say sage -n to run the notebook directly and sage -c to run a single command should definitely be kept. I personally use sage -t a lot for running tests (I know it can be replaced with python -m sage.doctest, but the shortcut is quite handy)

The current version seems to work fine to launch sage, but fails at exit. Running exit gives

sage: ERROR:prompt_toolkit.buffer:Loading history failed
Traceback (most recent call last):
  File "/usr/lib/python3.12/site-packages/prompt_toolkit/buffer.py", line 405, in load_history_done
    f.result()
  File "/usr/lib/python3.12/site-packages/prompt_toolkit/buffer.py", line 393, in load_history
    async for item in self.history.load():
  File "/usr/lib/python3.12/site-packages/prompt_toolkit/history.py", line 60, in load
    self._loaded_strings = list(self.load_history_strings())
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/IPython/terminal/interactiveshell.py", line 190, in load_history_strings
    for __, ___, cell in self.shell.history_manager.get_tail(
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get_tail'

Unhandled exception in event loop:
  File "/usr/lib/python3.12/site-packages/prompt_toolkit/buffer.py", line 393, in load_history
    async for item in self.history.load():
  File "/usr/lib/python3.12/site-packages/prompt_toolkit/history.py", line 60, in load
    self._loaded_strings = list(self.load_history_strings())
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/IPython/terminal/interactiveshell.py", line 190, in load_history_strings
    for __, ___, cell in self.shell.history_manager.get_tail(
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Exception 'NoneType' object has no attribute 'get_tail'
Press ENTER to continue...

and trying with CTRL+D gives

sage:                                                                                                                                                     
/usr/lib/python3.12/site-packages/sage/misc/banner.py:66: DeprecationWarning: Use sage.version instead.
See https://github.com/sagemath/sage/issues/1 for details.
  a("\n│ %-66s │\n" % version())

and displays the banner again. Pressing CTRL+D once again finally exits.

Documentation preview for this PR (built with commit 1a872e3; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

I'd say sage -n to run the notebook directly and sage -c to run a single command should definitely be kept. I personally use sage -t a lot for running tests (I know it can be replaced with python -m sage.doctest, but the shortcut is quite handy)

+1

Also sage <file> to run a file. This includes preparsing *.sage files, and compiling *.pyx files.

+100 on cleaning up the scripts

I agree sage -t is useful. The current cli has some quirks... maybe worth a cleanup at some point. With this PR and the new (meson) build I get:

$ python -m sage.doctest --all
Running doctests...
...
Doctesting entire Sage library.
Skipping '/tmp/tmpdir-tornaria/build-via-sdist-l1daqoy5/sagemath-10.6b6/src/sage/../../src/sage' because it does not have one of the recognized file name extensions
No files to doctest

so it seems the paths are not quite right, and also the build paths are leaking.

Similar experiment using the sagemath_standard wheel works fine (both using sage -t and python -m sage.doctest).

Build paths also leak on introspection. For example, if one does ZZ? you'll see the build file path reported. In fact, the file integer_ring.pyx is not shipped so no path can be shown here. For the same reason, doing ZZ?? will not show the source (this is unfortunate IMO).

OTOH, something like random? shows the correct path (the correct one inside the venv where I installed this wheel) and random?? shows the source.

If you can fix the 2 or 3 suggestions above, we can get this in even if it's still missing critical functionality so the new package is usable. Changes suggested:

• remove the deprecation (move to a separate PR where the users of that are also adjusted)
• remove the two lines in my last suggestion so the thing doesn't run "twice"
• make python -m sage.cli work
  The first two are trivial (just remove a few lines). The third one should be easy and desirable (so we can "play" with the cli easily even with sagemath-standard).

I'd say sage -n to run the notebook directly and sage -c to run a single command should definitely be kept. I personally use sage -t a lot for running tests (I know it can be replaced with python -m sage.doctest, but the shortcut is quite handy)

Took me a bit longer than expected to come back to this, sorry. The two options -n and -c are now reimplemented in the new interface. I'm not planning to add sage -t since this a) should be replaced by pytest in the near future and b) is mostly relevant for devs and not actual users (and devs can just run the local ./sage -t in the root).

The other mentioned issues (exit issues, python -m cli support, etc) should be fixed as well now.

Took me a bit longer than expected to come back to this, sorry. The two options -n and -c are now reimplemented in the new interface.

Thanks, this is looking good.

I'm not planning to add sage -t since this a) should be replaced by pytest in the near future and b) is mostly relevant for devs and not actual users (and devs can just run the local ./sage -t in the root).

a) As much as I agree with on the need to move to standard tooling (like pytest), we have 20 years of doctests, they are not going to be moved to pytest any time soon.

b) Devs are users, in fact the main users from my pov.

c) Here's one important usage: I can write a script in a single *.sage (or *.py), and I can run

$ sage test.sage
[runs the script]

and my script can have functions with doctests and I can easily test them with

$ sage -t test.sage
[runs the tests]

This works with the current sage script, and should keep working. I think it's ok if we make some (minimal) changes in the cli to improve (make it easier to maintain and remove a lot of warts), but removing important functionality is a difficult sell...

The other mentioned issues (exit issues, python -m cli support, etc) should be fixed as well now.

Nice. I'll make some comments on the code later, but this is looking good. I am still using sagemath-standard with this PR merged in, and I am using alias sage-cli='python -m sage.cli' to play with this.

Took me a bit longer than expected to come back to this, sorry. The two options -n and -c are now reimplemented in the new interface.

Thanks, this is looking good.

I'm not planning to add sage -t since this a) should be replaced by pytest in the near future and b) is mostly relevant for devs and not actual users (and devs can just run the local ./sage -t in the root).

a) As much as I agree with on the need to move to standard tooling (like pytest), we have 20 years of doctests, they are not going to be moved to pytest any time soon.

it's not that anything needs to be moved.
Pytest can test docstrings in python files just fine.
With cython it's a bit harder, but most probably nothing needs to be changed, either.

b) Devs are users, in fact the main users from my pov.

c) Here's one important usage: I can write a script in a single *.sage (or *.py), and I can run

$ sage test.sage
[runs the script]

and my script can have functions with doctests and I can easily test them with

$ sage -t test.sage
[runs the tests]

This works with the current sage script, and should keep working. I think it's ok if we make some (minimal) changes in the cli to improve (make it easier to maintain and remove a lot of warts), but removing important functionality is a difficult sell...

we can make sage -t to just call pytest.

the failing

sage -t --warn-long 5.0 --random-seed=306843490678697062143679095807789091604 src/sage/rings/polynomial/plural.pyx  # SignalError in doctesting framework

isn't relevant here as far as I can see.

The sage-ipython command is used in sage/interfaces/sage0.py for the Sage pexpect interface, in order to start a sage session without any bells and whistles. What's the plan here? Maybe the sage command could forward all unused parameters to ipython?

Based on a quick look, I would say in sage0 one could simply call python with an init script that sets up a SageTerminalApp with the necessary options.

Maybe the sage command could forward all unused parameters to ipython?

The disadvantage here would be that one doesn't get a meaningful error if one mistypes a command (e.g. sage -n0tebook would then call ipython with -n0tebook). Perhaps an idea would be to have a special cmd arg --ipython which then accepts all parameter and passes them along.

It would be good to still have a way to trigger the simple mode from the command line. This also affects some third-party UIs (eg. KDE's cantor [1]), which communicate with the sage process via terminal output and thus need to disable all coloring/banner/etc. Currently there's no clear way how to achieve that with meson-built sage.

[1] https://invent.kde.org/education/cantor/-/blob/v24.12.3/src/backends/sage/sagesession.cpp?ref_type=tags#L107

Another issue: the missing sage-cleaner executable breaks running the test suite, many of the modules fail with cryptic Bad exit: 1 errors.

I will open an issue to track all test suite regression in the meson build, I assume these aren't caught by the CI because the executables are still present in the source tree.

I will open an issue to track all test suite regression in the meson build, I assume these aren't caught by the CI because the executables are still present in the source tree.

Done: #39872

version() is the first command I ever type into most sage notebooks, so bummer it is deprecated.

Second, the deprecation prints out "Use sage.version instead." which isn't as clear as it claims to be:

/tmp/ipykernel_4061/2131152398.py:1: DeprecationWarning: Use sage.version instead.
See https://github.com/sagemath/sage/issues/39015 for details.
  version()

Unfortunately, doing "sage.version" doesn't really work as advertised and in fact what works is "sage.version.version" (not as a function), which takes several tries to figure out:

Finally, having version is standard in libraries and was in sage, but got broken. I reopened that ticket.

in the context of notebooks, it's not clear to me what version() should mean. A notebook created in one jupyter kerner version might not work in another.

The wording is perhaps not the best, but a general reference to the module sage.version was intended. For example, you might want to use the full version banner or the simple version string, depending on your needs. version() was very misleading in this regard.

This is what I see in Sage 10.8beta6:

sage: version()
<ipython-input-28-e742030be3c2>:1: DeprecationWarning: Use sage.version instead.
See https://github.com/sagemath/sage/issues/39015 for details.
  version()
'SageMath version 10.8.beta6, Release Date: 2025-10-06'

sage: sage.version
<module 'sage.version' from '/usr/local/sage/src/sage/version.py'>

and I'm confused what is the suggested replacement for version().

Can this DeprecationWarning be made more clear?

@antonio-rojas Hi. I recently installed Sage 10.7 in ArchLinux WSL2. However, I get the following problem after clean install:

[r4sti@REDACTED final]$ uname -r
6.6.87.2-microsoft-standard-WSL2
[r4sti@REDACTED final]$ cat /etc/os-release | grep NAME
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
[r4sti@REDACTED  final]$ sage -python3 test.py
usage: sage [-h] [-v] [-q] [--simple-prompt] [-V] [-n [{jupyter,jupyterlab}]] [-c [COMMAND]] [file]
sage: error: unrecognized arguments: -python3

This worked like a charm for Ubuntu installation (sudo apt install sagemath).

I was suggested that a revert to use the old bash script should be done, until the new meson-based CLI has compatible functionality.

Is this something you can take care of?

Thanks in advance.

I was suggested that a revert to use the old bash script should be done, until the new meson-based CLI has compatible functionality.

Is this something you can take care of?

There's nothing to implement, the old sage -python3 is exactly the same as python3. Where did you get that suggestion from?

I suggested that one.

That said, making sage -python3 print a message use python3 ... instead would have been useful for the users. It isn't at all clear how the sage environment interact with the usual python environment.

but more generally: we have a deprecation policy such that features cannot be removed before one year of deprecation. It is not clear that policy applies only to "Python classes or functions without underscore in its name" (*) or also to other utilities, but if the latter were the case, the correct course of action would be to add it back (possibly with deprecation warnings).

(*): from https://doc.sagemath.org/html/en/developer/coding_in_python.html#deprecation

Any class, function, method, or attribute defined in a file under SAGE_ROOT/src/sage is subject to the deprecation policy. If its name starts with an underscore, then it is considered internal, and exempt from the deprecation policy.

I can't find anything that discuss backwards incompatible change to utilities outside src/sage, but there might have been discussion about it elsewhere.