Just Crazy

[Marc Culler]

After finally getting Sage 10.8beta5 to build in the context which I need for the Sage_macOS app, I built the app, only to find that it is completely broken.  The reason turns out to be that the main sage executable (sage/venv/bin/sage) has completely changed.  The long bash script which parses the options and sources other bash scripts to construct the execution environment has been replaced by a python script which works completely differently and seems to support a different set of options.

The new version may well be an improvement.  I can't say yet.  But the idea that something as core as the main sage executable would get changed in a fundamental and backwards incompatible way between two beta releases, without any warning or any discussion at all, is mind boggling. As the subject line says, it is just crazy.  No serious software development project works that way.

- Marc

[Marc Culler]

This is regarding the options which were eliminated in the  new stealth-replaced backwards-incompatible sage executable.

One important option which was very useful to me, and which is now gone, allowed specifying the directory where notebooks are stored:

usage: sage [-h] [-v] [-q] [--simple-prompt] [-V] [-n [{jupyter,jupyterlab}]] [-c [COMMAND]] [file]
sage: error: unrecognized arguments: --notebook-dir=/Users/culler/Documents/Sage

- Marc

[David Roe]

I'm having trouble figuring out where this change was introduced.  The folder sage/venv doesn't exist in the repo, so presumably sage/venv/bin/sage is copied from elsewhere during the build process, but I wasn't able to figure out where in a few minutes of poking around.  Similarly, I don't see any obvious PR descriptions in 10.8beta5 changelog.

David

--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sage-devel/c33aa6a2-9c89-436e-a5f1-47dcfadc03d3n%40googlegroups.com.

[Antonio Rojas]

El miércoles, 1 de octubre de 2025 a las 17:47:02 UTC+2, David Roe escribió:

I'm having trouble figuring out where this change was introduced.  The folder sage/venv doesn't exist in the repo, so presumably sage/venv/bin/sage is copied from elsewhere during the build process, but I wasn't able to figure out where in a few minutes of poking around.  Similarly, I don't see any obvious PR descriptions in 10.8beta5 changelog.

David

It was introduced in beta2, not beta5, so quite early in the 10.8 development cycle. The relevant PR is https://github.com/sagemath/sage/pull/39030. In any case, saying that something was changed "between two beta releases" is completely meaningless in Sage: a beta is simply a weekly development snapshot, literally every single change is done between two beta releases. 

[Marc Culler]

Sure.  The main point is that this change is a breaking change and it was made with no general discussion and no warning.  (No doubt there was some discussion in the PR, but that is not really the same thing.)

David,  there is no venv directory in the source.  It is a symlink created during the build process.  It points to Sage's internal venv.  Usually it looks something like:

venv -> local/var/lib/sage/venv-python3.X.Y

The file that I referred to as sage/venv/bin/sage is the main executable of sage.  It could also be named sage/local/bin/sage, and I believe that it was named that before the venv was added.

- Marc

[Tobia...@gmx.de]

The "new" Python-based CLI is actually almost a year old by now and was originally introduced in https://github.com/sagemath/sage/pull/39015 and since then extended and improved by various contributors but most notably by Anonio (thanks!).

Importantly, this updated CLI was already included in the stable Sage 10.7 release. In fact, it is the version you’ll get if you install the Sage 10.7 package from Arch Linux (https://archlinux.org/packages/extra/x86_64/sagemath/). I'm not aware of any major complains from the Arch users though a few minor issues still cropped up - eg https://github.com/sagemath/sage/pull/40872 fixes one such case. 

In any case, if you encounter any bugs or missing features I suggest you open an issue (or even better a PR) on Github, and I'm sure that they will be fixed soon.

[Marc Culler]

Indeed, the change from the bash script to the new python script is pretty well obfuscated.

The old bash script still exists as src/bin/sage but it is not used.  To see where the new python replacement gets created you have to look inside the file sage/pyproject.toml.  There you find:

[project.scripts]
sage = "sage.cli:main"

which causes the actual sage executable to get built.

- Marc

PS Incidentally, and completely unrelated, the pyproject.toml file also contains a deprecated license classifier:

    "License :: OSI Approved :: GNU General Public License v2 or later (GPLv2+)",

which is no longer allowed.  Instead there is supposed to be a license field in the project block.

[David Roe]

On Wed, Oct 1, 2025 at 12:13 PM Marc Culler <marc....@gmail.com> wrote:

Sure.  The main point is that this change is a breaking change and it was made with no general discussion and no warning.  (No doubt there was some discussion in the PR, but that is not really the same thing.)

I agree that this change should have had more discussion on sage-devel, as has been discussed in this sage-devel thread, for example.  But we can't change that at this point, so the question is where to go from here.  Here are some possible next steps:

1. Create more explicit criteria for what kinds of PRs need to be announced/voted on sage-devel.  I think a reasonable first approximation for a criterion would be "substantially affects developers who are working on other parts of Sage."  So, Sage-wide changes that are backward compatible wouldn't need to be announced; local changes to the p-adics folder wouldn't need to be announced; breaking changes to build or testing processes, or changes to category infrastructure that's included across sage would be.

2. Identify the backward incompatible changes in #39030 (and elsewhere, such as #39015).  At some point, the public interface to the sage script consisted of the output of sage -advanced, which I've copied below (from 10.7).  Since --notebook-dir does not appear there, is there another place where command line options that used to be supported are documented (I don't really want to try to figure this out by reading a bunch of bash scripts).  And for the new command line interface, is the list of options documented somewhere?  Marc's answer about pyproject.toml still doesn't tell me where to find the Python code that's actually being run when you type sage.  Once we have a list of differences, we can more productively discuss which need to be supported before 10.8 can be released, and what a better deprecation process might look like for the others.

3. I will echo John's request made here: it would be very nice to have a high level overview of these changes, both the ones that have been made and the ones that still need work.

Let me close by saying that I appreciate all the work that Tobias and Antonio are putting in making meson build Sage.  It's not something I personally want to work on, and I appreciate that there are people out there trying to make Sage better in this way.

David

Output of sage-advanced in 10.7

SageMath version 10.7, Release Date: 2025-08-09

Running Sage, the most common options:

  file.[sage|py|spyx] -- run given .sage, .py or .spyx file
  -c cmd              -- evaluate cmd as sage code. For example,
                         "sage -c 'print(factor(35))'" will
                         print "5 * 7".

Running Sage, other options:

  --preparse file.sage -- preparse "file.sage", and produce
                          the corresponding Python file
                          "file.sage.py"
  -q                  -- quiet; start with no banner
  --min               -- do not populate global namespace
                         (must be first option)
  --nodotsage         -- run Sage without using the user's
                         .sage directory: create and use a temporary
                         .sage directory instead.
  --gthread, --qthread, --q4thread, --wthread, --pylab
                      -- pass the option through to IPython
  --simple-prompt     -- pass the option through to IPython: use
                         this option with sage-shell mode in emacs
  --gdb               -- run Sage under the control of gdb
  --lldb              -- run Sage under the control of lldb

Running external programs:

  --cython [...]      -- run Cython with the given arguments
  --ecl [...], --lisp [...]  -- run Sage's copy of ECL (Embeddable
                                Common Lisp) with the given arguments
  --gap [...]         -- run Sage's Gap with the given arguments
  --gap3 [...]        -- run Sage's Gap3 with the given arguments
                         (not installed currently, run sage -i gap3)
  --git [...]         -- run Sage's Git with the given arguments
  --gp [...]          -- run Sage's PARI/GP calculator with the
                         given arguments
  --ipython [...], --ipython3 [...]
                      -- run Sage's IPython using the default
                         environment (not Sage), passing additional
                         additional options to IPython
  --jupyter [...]     -- run Sage's Jupyter with given arguments
  --kash [...]        -- run Sage's Kash with the given arguments
                         (not installed currently, run sage -i kash)
  --M2 [...]          -- run Sage's Macaulay2 with the given arguments
                         (not installed currently, run sage -i macaulay2)
  --maxima [...]      -- run Sage's Maxima with the given arguments
  --mwrank [...]      -- run Sage's mwrank with the given arguments
  --pip [...]         -- invoke pip, the Python package manager
  --polymake [...]    -- run Sage's Polymake with given arguments
                         (not installed currently, run sage -i polymake)
  --python [...], --python3 [...]
                      -- run the Python 3 interpreter
  -R [...]            -- run Sage's R with the given arguments
  --singular [...]    -- run Sage's singular with the given arguments
  --sqlite3 [...]     -- run Sage's sqlite3 with given arguments

Running the notebook:

  -n [...], --notebook=[...]
                      -- start the notebook; valid options include
                         'default', 'jupyter', 'jupyterlab', and 'export'.
                         Current default is 'jupyter'.
                         Run "sage --notebook --help" for more details.

Testing files:

  -t [options] <files|dir> -- test examples in .py, .pyx, .sage
                              or .tex files.  Options:
     --long           -- include lines with the phrase 'long time'
     --verbose        -- print debugging output during the test
     --all            -- test all files
     --optional       -- also test all examples labeled "# optional"
     --only-optional[=tags]
                      -- if no 'tags' are specified, only run
                         blocks of tests containing a line labeled
                         "# optional". If a comma-separated
                         list of tags is specified, only run block
                         containing a line labeled "# optional tag"
                         for any of the tags given, and in these blocks
                         only run the lines which are unlabeled or
                         labeled "# optional" or labeled
                         "# optional tag" for any of the tags given.
     --randorder[=seed] -- randomize order of tests
     --random-seed[=seed]  -- random seed (integer) for fuzzing doctests
     --new            -- only test files modified since last commit
     --initial        -- only show the first failure per block
     --debug          -- drop into PDB after an unexpected error
     --failed         -- only test files that failed last test
     --warn-long [timeout] -- warn if tests take too much CPU time
     --only-errors    -- only output failures, not successes
     --gc=GC          -- control garbage collection (ALWAYS:
                         collect garbage before every test; NEVER:
                         disable gc; DEFAULT: Python default)
     --short[=secs]   -- run as many doctests as possible in about 300
                         seconds (or the number of seconds given.) This runs
                         the tests for each module from the top of the file
                         and skips tests once it exceeds the budget
                         allocated for that file.
     --help           -- show all doctesting options
  --tnew [...]        -- equivalent to -t --new
  -tp <N> [...]       -- like -t above, but tests in parallel using
                         N threads, with 0 interpreted as min(8, cpu_count())
  --testall [options] -- equivalent to -t --all

  --coverage <files>  -- give information about doctest coverage of files
  --coverageall       -- give summary info about doctest coverage of
                         all files in the Sage library
  --startuptime [module] -- display how long each component of Sage takes to
                         start up; optionally specify a module to get more
                         details about that particular module
  --tox [options] <files|dirs> -- general entry point for testing
                                  and linting of the Sage library
     -e <envlist>     -- run specific test environments; default:
                         ROOT:,will,run,in,automatically,provisioned,tox,,host,/opt/homebrew/Cellar/tox/4.28.4/libexec/bin/python,is,missing,[requires,(has)]:,tox<4.14.1,(4.28.4),ROOT:,install_deps,/Users/roed/sage/sage-10.7/src>,python,-I,-m,pip,install,tox,'tox<4.14.1','tox>=3.18',ROOT:,provision>,src/.tox/.tox/bin/python,-m,tox,-c,/Users/roed/sage/sage-10.7/src,--listenvs,doctest,coverage,startuptime,pycodestyle-minimal,relint,codespell,rst,ruff-minimal
        doctest                -- run the Sage doctester
                                  (same as "sage -t")
        coverage               -- give information about doctest coverage of files
                                  (same as "sage --coverage[all]")
        startuptime            -- display how long each component of Sage takes to start up
                                  (same as "sage --startuptime")
        pycodestyle-minimal    -- check against Sage minimal style conventions
        relint                 -- check whether some forbidden patterns appear
        codespell              -- check for misspelled words in source code
        rst                    -- validate Python docstrings markup as reStructuredText
        ruff-minimal           -- check against Sage minimal style conventions
        coverage.py            -- run the Sage doctester with Coverage.py
        coverage.py-html       -- run the Sage doctester with Coverage.py, generate HTML report
        coverage.py-xml        -- run the Sage doctester with Coverage.py, generate XML report
        pyright                -- run the static typing checker pyright
        pycodestyle            -- check against the Python style conventions of PEP8
        cython-lint            -- check Cython files for code style
        ruff                   -- check against Python style conventions
     -p auto          -- run test environments in parallel
     --help           -- show tox help
  --pytest [options] <files|dirs> -- run pytest on the Sage library
     --help           -- show pytest help

Some developer utilities:

  --grep [options] <string>
                      -- regular expression search through the Sage
                         library for "string". Any options will
                         get passed to the "grep" command.
  --grepdoc [options] <string>
                      -- regular expression search through the
                         Sage documentation for "string".
  --search_src ...    -- same as --grep
  --search_doc ...    -- same as --grepdoc
  --fixdoctests file.py
                      -- Run doctests and replace output of failing doctests
                         with actual output.
  --fixdistributions <files|dirs>
                      -- Check or update '# sage_setup: distribution'
                         directives in source files
  --sh [...]         -- run a shell with Sage environment variables
                        as they are set in the runtime of Sage
  --cleaner          -- run the Sage cleaner.  This cleans up after Sage,
                        removing temporary directories and spawned processes.
                        (This gets run by Sage automatically, so it is usually
                        not necessary to run it separately.)
File conversion:

  --rst2ipynb [...]   -- Generates Jupyter notebook (.ipynb) from standalone
                         reStructuredText source.
                         (not installed currently, run sage -i rst2ipynb)
  --ipynb2rst [...]   -- Generates a reStructuredText source file from
                         a Jupyter notebook (.ipynb).

Valgrind memory debugging:

  --cachegrind        -- run Sage using Valgrind's cachegrind tool.  The log
                         files are named sage-cachegrind.PID can be found in
                         $DOT_SAGE
  --callgrind         -- run Sage using Valgrind's callgrind tool.  The log
                         files are named sage-callgrind.PID can be found in
                         $DOT_SAGE
  --massif            -- run Sage using Valgrind's massif tool.  The log
                         files are named sage-massif.PID can be found in
                         $DOT_SAGE
  --memcheck          -- run Sage using Valgrind's memcheck tool.  The log
                         files are named sage-memcheck.PID can be found in
                         $DOT_SAGE
  --omega             -- run Sage using Valgrind's omega tool.  The log
                         files are named sage-omega.PID can be found in
                         $DOT_SAGE
  --valgrind          -- this is an alias for --memcheck

Getting help:

  -v, --version       -- display Sage version information
  --dumpversion       -- print brief Sage version
  -h, -?, --help      -- print a short help message
  --advanced          -- list all command line options

Building the Sage library:

  -b                  -- build Sage library -- do this if you have
                         modified any source code files in SAGE_ROOT/src/sage/
  -ba                 -- same as -b, but rebuild *all* Cython
                         code.
  -br                 -- build and run Sage

  -bt [...]           -- build Sage and test; same options as -t
  -btp <N> [...]      -- build Sage and test in parallel; same options as -tp
  -btnew [...]        -- build Sage and test modified files, as in -t --new

  -bn [...], --build-and-notebook [...]
                      -- build the Sage library (as by running "sage -b")
                         and then start the notebook

Package handling:

  --package [args]    -- call the package manager with given arguments.
                         Run without arguments for help.
  --experimental      -- list all experimental packages that can be installed
  -i [opts] [pkgs]    -- install the given Sage packages.  Options:
                           -c -- run the packages' test suites,
                                 overriding the settings of
                                 SAGE_CHECK and SAGE_CHECK_PACKAGES
                           -d -- only download, do not install packages
                           -f -- force build: install the packages even
                                 if they are already installed
                           -s -- do not delete the temporary build directories
                                 after a successful build
                           -y -- reply yes to prompts about experimental
                                 and old-style packages; warning: there
                                 is no guarantee that these packages will
                                 build correctly; use at your own risk
                           -n -- reply no to prompts about experimental
                                 and old-style packages
  -f [opts] [pkgs]    -- shortcut for -i -f: force build of the given Sage
                         packages
  -p [opts] [packages]-- install the given Sage packages, without dependency
                         checking. Options are the same as for the -i command.
  --optional          -- list all optional packages that can be installed
  --standard          -- list all standard packages that can be installed
  --installed         -- list all installed packages

Making Sage distributions:

  --sdist             -- build a source distribution of Sage

Building the documentation:

  --docbuild [lang/]<document> <html|pdf|...> -- Build the Sage documentation

Other developer tools:

  --root              -- print the Sage root directory
  --git-branch        -- print the current git branch
  --buildsh [...]     -- run a shell with Sage environment variables
                         as they are set while building Sage and its packages

David,  there is no venv directory in the source.  It is a symlink created during the build process.  It points to Sage's internal venv.  Usually it looks something like:

venv -> local/var/lib/sage/venv-python3.X.Y

The file that I referred to as sage/venv/bin/sage is the main executable of sage.  It could also be named sage/local/bin/sage, and I believe that it was named that before the venv was added.

- Marc

On Wednesday, October 1, 2025 at 11:00:13 AM UTC-5 Antonio Rojas wrote:

El miércoles, 1 de octubre de 2025 a las 17:47:02 UTC+2, David Roe escribió:

I'm having trouble figuring out where this change was introduced.  The folder sage/venv doesn't exist in the repo, so presumably sage/venv/bin/sage is copied from elsewhere during the build process, but I wasn't able to figure out where in a few minutes of poking around.  Similarly, I don't see any obvious PR descriptions in 10.8beta5 changelog.

David

It was introduced in beta2, not beta5, so quite early in the 10.8 development cycle. The relevant PR is https://github.com/sagemath/sage/pull/39030. In any case, saying that something was changed "between two beta releases" is completely meaningless in Sage: a beta is simply a weekly development snapshot, literally every single change is done between two beta releases. 

--

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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/fa36cbd2-ac07-46fe-a172-3578f7bcd163n%40googlegroups.com.

[Marc Culler]

 Marc's answer about pyproject.toml still doesn't tell me where to find the Python code that's actually being run when you type sage.

It runs the code in the file sage/venv/bin/sage, which is an entry point generated automatically by the build system.  That file contains the following (where the actual shebang depends on the location of the sage directory):

#!/path/to/sage/local/bin/python3
# -*- coding: utf-8 -*-
import re
import sys
from sage.cli import main
if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])
    sys.exit(main()) 

- Marc

[David Roe]

Thanks Marc, that helps a lot.

Looking at the cli folder, it only supports a small fraction of the command line options of the old bash script.  Personally, I think this model is a lot better and more maintainable, but we should revert to bash script until the new argument parser supports all of the options that the old one did (options being dropped could be okay, but need to be justified).

David

--

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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CALcZXREPnPAv9j0wXnm6UprB%2BCB2qXjBgDLn13i6GQnz0Q88PQ%40mail.gmail.com.

[Michael Orlitzky]

On 2025-10-01 14:23:31, David Roe wrote:
> 2. Identify the backward incompatible changes in #39030

> <https://github.com/sagemath/sage/pull/39030> (and elsewhere, such as #39015
> <https://github.com/sagemath/sage/pull/39015>). At some point, the public

> interface to the sage script consisted of the output of sage -advanced,
> which I've copied below (from 10.7).

For some context, since no one has explained WHY there's a new script
yet. The goal was to make sage usable as a normal python package:
installable via pip, capable of being depended upon by 3rd party
packages, usable on linux distributions, etc. -- independent of the
sage distribution.

The bash script is not suitable in any of those cases. Bash itself is
not a dependency of the sage library, and you can't require it if you
want to run on (say) Windows. The bash script relies on variables like
SAGE_ROOT to find things, but those variables don't exist outside of
the sage distribution. Most imporantly, a huge number of options refer
to things that only make sense in the sage distribution:

* sage -b and everything related
* sage -i and everything related
* sage --python, sage --maxima, sage --gap3(!), etc.
* sage --package, sage --optional, ...

As such, we can't just install the bash script if the user does "pip
install sagemath". But, we still need a way to actually start sage
once it's installed! The new script reimplements the critical parts in
python, and is installed by sagelib itself, so that after you install
sage by one of those other methods, you can just type "sage" and it
will work.

None of that precludes further improvements to the python script,
though, and it might be possible to revert to the bash script for the
sage distribution.

[Marc Culler]

Another useful option which got removed is --python.  It is sometimes useful to be able to check if something works in the same python that sage runs in, and it is not necessarily obvious which one that is when there are multiple versions of python installed.  Even on linux it is possible to have more than one python installed.  So I would urge adding that one to the entry point.

- Marc

[Dima Pasechnik]

On Wed, Oct 1, 2025 at 2:06 PM Michael Orlitzky <mic...@orlitzky.com> wrote:

On 2025-10-01 14:23:31, David Roe wrote:
> 2. Identify the backward incompatible changes in #39030
> <https://github.com/sagemath/sage/pull/39030> (and elsewhere, such as #39015
> <https://github.com/sagemath/sage/pull/39015>).  At some point, the public
> interface to the sage script consisted of the output of sage -advanced,
> which I've copied below (from 10.7).

For some context, since no one has explained WHY there's a new script
yet. The goal was to make sage usable as a normal python package:
installable via pip, capable of being depended upon by 3rd party
packages, usable on linux distributions, etc. -- independent of the
sage distribution.

The bash script is not suitable in any of those cases. Bash itself is
not a dependency of the sage library, and you can't require it if you
want to run on (say) Windows. The bash script relies on variables like
SAGE_ROOT to find things, but those variables don't exist outside of
the sage distribution. Most imporantly, a huge number of options refer
to things that only make sense in the sage distribution:

a number of these things stopped making sense, or are broken, or there are better ways. 

  * sage -b and everything related

No longer needed (yes, your changed Cython code is now being rebuilt on the fly, as if it's Python!)

If in doubt, just run "make"

 

  * sage -i and everything related

some of it is broken, and "make foobar42" replaces "sage -i foobar" (not sure how broken it is now)

  * sage --python, sage --maxima, sage --gap3(!), etc.
  * sage --package, sage --optional, ...

As such, we can't just install the bash script if the user does "pip
install sagemath". But, we still need a way to actually start sage
once it's installed! The new script reimplements the critical parts in
python, and is installed by sagelib itself, so that after you install
sage by one of those other methods, you can just type "sage" and it
will work.

None of that precludes further improvements to the python script,
though, and it might be possible to revert to the bash script for the
sage distribution.

At the very least, the bash script should be updated to make sense, as I noticed above,

and what's implemented in the python script should be called via it, so that

not to create burden to maintain two things in parallel.

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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/aN17lXWCI2TApk4W%40jumba.

[Dima Pasechnik]

I am sorry, what does make you think that `./sage --python` is removed?

Are you talking about an internal script? If so, it's certainly a fair game to change,

it's not something user-facing, or something that's used by many developers.

$ ./sage
┌────────────────────────────────────────────────────────────────────┐
│ SageMath version 10.8.beta5, Release Date: 2025-09-27              │

$ ./sage --python

Python 3.13.5 (main, Jul 15 2025, 09:22:39) [GCC 14.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>>

--

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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/460c019e-535d-4f1f-86a7-a3be2a158b8bn%40googlegroups.com.

[David Roe]

On Wed, Oct 1, 2025 at 3:55 PM Dima Pasechnik <dim...@gmail.com> wrote:

I am sorry, what does make you think that `./sage --python` is removed?

Looking at the argument parser defined in the cli folder, I don't see  --python added anywhere, so I would expect the behavior that Marc describes rather than what Dima observes.  Dima, do you know what code path ./sage --python goes through?

David

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq16Z534izfB3kjFWa%2BP%3DF15aiUvb3vYKE3AZP%2BML22xww%40mail.gmail.com.

[Antonio Rojas]

El miércoles, 1 de octubre de 2025 a las 20:23:49 UTC+2, David Roe escribió:

2. Identify the backward incompatible changes in #39030 (and elsewhere, such as #39015).  At some point, the public interface to the sage script consisted of the output of sage -advanced, which I've copied below (from 10.7).  Since --notebook-dir does not appear there, is there another place where command line options that used to be supported are documented (I don't really want to try to figure this out by reading a bunch of bash scripts).  And for the new command line interface, is the list of options documented somewhere?  

--notebook-dir was never a Sage option. It is a jupyter notebook option which the old sage-notebook script just forwarded to it. It shouldn't be hard to implement this forwarding in the python script.

[Dima Pasechnik]

On Wed, Oct 1, 2025 at 2:58 PM David Roe <roed...@gmail.com> wrote:

On Wed, Oct 1, 2025 at 3:55 PM Dima Pasechnik <dim...@gmail.com> wrote:

I am sorry, what does make you think that `./sage --python` is removed?

Looking at the argument parser defined in the cli folder, I don't see  --python added anywhere, so I would expect the behavior that Marc describes rather than what Dima observes.  Dima, do you know what code path ./sage --python goes through?

It's in src/bin/sage

if [ "$1" = '-python' -o "$1" = '--python' -o  "$1" = '-python3' -o "$1" = '--python3' ]; then
    shift
    exec python3 "$@"

 

As as venv/bin/sage is concerned, it's could be that in the past it was more or less a copy of src/bin/sage,

but it's no longer the case. It doesn't mean that ./sage is replaced by a Python script, it's simply not the case.

Dima

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CAChs6_m522NFicEJj1VzR%2BAg%2Bdi-DUtckUSWa4f3YXmmiCwsiA%40mail.gmail.com.

[Dima Pasechnik]

To summarise, nothing is "Crazy" here, from sage the distro point of view.
Internal scripts in venv/ are not what they used to be, but they were never intended for direct public consumption.

It's true though that several scripts in src/bin/ are overdue for maintenance.
In particular I can take care of sage -b and sage -i, by replacing them with noops (and printing  info on how to proceed).

Dima

[Marc Culler]

On Wed, Oct 1, 2025 at 4:27 PM Dima Pasechnik <dim...@gmail.com> wrote:

To summarise, nothing is "Crazy" here, from sage the distro point of view.

Nobody said anything was crazy from the "sage the distro point of view".  Nor did anyone say that these changes made things worse.

I did say it is "crazy" to make breaking changes without any public discussion and without any warning for those people who will be affected.  I stand by that.  No well-run software project does that.  And trying to justify doing it by making false claims that there is only one person who will be affected is ludicrous.

- Marc

[Dima Pasechnik]

What breaking changes do you mean? Everything around ./sage works (or "works") as before. 

Let's sort it out. I think your claim is just rushed and incorrect. 

You start an internal script instead of the canonical ./sage, and act surprised that they are not doing the same thing.

If an internal undocumented stuff changed, and you relied on it in your work, it's not something crazy or ludicrous.  Why did you assume that venv/bin/sage is what ./sage is using? 

Dima

- Marc

--
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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CALcZXRFjATZjM8qVv3mPyr2u8oNg9dA0w%2B%3DMhyV28u8iZTPVCA%40mail.gmail.com.

[Dima Pasechnik]

this removes the only mention of `venv/bin/sage` I found in the repo. It was somewhere at the bottom of our README.md,

where it was explained how make a symbolic link to `./sage`.

https://github.com/sagemath/sage/pull/40954

Dima

[Marc Culler]

On Wednesday, October 1, 2025 at 7:20:28 PM UTC-5 dim...@gmail.com wrote:

.  Why did you assume that venv/bin/sage is what ./sage is using?

You are right that I have been making some assumptions.  Not that venv/bin/sage is what the so-called "./sage" is using; not even that venv/bin/sage and the so-called "./sage" are identical, even though that has been true since the venv was added.  I was assuming that the venv functions as a venv and that the sage script functions as an entry point for that venv.  (One of many - the venv/bin directory is quite large, and all of the scripts in it function as entry points.)  They are not exactly entry points, since they are not advertised in the package metadata since there is no package metadata since there is no package (yet).  And the venv has not been a "real" venv until very recently, since it did not contain a pyvenv.cfg file.  But it was more or less a venv and the sage script was more or less an entry point for it, so the natural place for the sage script to live would be in the venv/bin directory.  And, sure enough, there it was - right there in the venv/bin directory. It is true that there was also a copy in the top level sage directory.  I assumed that was for backwards compatibility, since the venv was a relatively new addition to Sage.

- Marc 

[Tobia...@gmx.de]

They are not exactly entry points, since they are not advertised in the package metadata since there is no package metadata since there is no package (yet).

I don't understand what you mean with this sentence. There is a sagemath package, defined in the pyproject.toml file in the root, whose metadata (project.scripts) declares the entry point "sage" with implementation in the Python module "sage.cli". This is the standard way how Python projects register scripts/entry points, i.e. create executables in venv/bin upon installation.

[Tobia...@gmx.de]

2. Identify the backward incompatible changes in #39030 (and elsewhere, such as #39015).

I believe there are no direct backwards-incompatible changes:

-  If you build Sage from source using sage-the-distro (or your distribution does this), you can continue using the <root>/sage script without modification.

-  If you build Sage directly with meson, then #39030  introduced no changes for you

The only real backwards-incompatible case arises if you migrate from sage-the-distro to the meson-based library. We’ve tried to make this transition as smooth and compatible as possible, but a fully backwards-compatible migration isn’t realistic. As Michael mentioned above, you also wouldn’t want to bring along all the baggage from the sage-the-distro era.

[Marc Culler]

Mostly I just meant that things are in transition.  I should have said that there is no pip package.

When I look in sage/lib/python3.13/lib/site-packages I see:

sage
sage_conf-10.8b5.dist-info
sage_conf.py
sage_docbuild
sage_docbuild-10.8b5.dist-info
sage_numerical_backends_coin
sage_numerical_backends_coin-10.4.dist-info
sage_setup
sage_setup-10.8b5.dist-info

So it looks to me like sage_conf, sage_docbuild, sage_numerical_backends_coin and sage_setup all have metadata but sage does not.  There is no sage-10.8.dist-info.  I agree there is a sage package, meaning there is a directory named "sage" containing a file named "__init__.py", but that package is different from most of the other packages (all except omp, I think) which have dist-info directories containing metadata.  I think that just means that while sage is technically a python package, it is not a package installed by pip, and as such it does not have metadata, so it does not advertise its entry points in the way that pip-installed packages do.

- Marc

On Thu, Oct 2, 2025 at 1:53 AM 'Tobia...@gmx.de' via sage-devel <sage-...@googlegroups.com> wrote:

They are not exactly entry points, since they are not advertised in the package metadata since there is no package metadata since there is no package (yet).

I don't understand what you mean with this sentence. There is a sagemath package, defined in the pyproject.toml file in the root, whose metadata (project.scripts) declares the entry point "sage" with implementation in the Python module "sage.cli". This is the standard way how Python projects register scripts/entry points, i.e. create executables in venv/bin upon installation.

--
You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/t5Nxu61MhMI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sage-devel/d94c02a7-93ec-4bb7-a504-df25b931cb35n%40googlegroups.com.