Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
script(s) to help with the transition to a single Sage repository
Python Shell C
branch: master

This branch is 48 commits behind sagemath:master

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.
fast-export
post-process_files
sagedev
.gitignore
README.rst
combinat.rst
configuration.sh
consolidate-repos.sh
failed_doctests.txt
git-filter-branch
post-process.sh
workflow-sep.rst

README.rst

sage-workflow

This is a repository for various stuff we're working on for the Workflow SEP (Sage Enhancement Proposal).

consolidate-repos.sh

This is a script which will ultimately take a (sufficiently recent) Sage release source tarball and convert it into another tarball. The new tarball will be similar to the original, i.e. it will be a source tarball which you will extract, enter the extracted directory, do make, wait a long time, and then end up with a working copy of Sage.

The difference will be that now there will be a single, consolidated git repo sitting in the top level directory. The repo will contain within it the Sage library, the Sage scripts, the Sage root scripts (i.e. the stuff other than SPKGs which you usually see when you extract a source tarball), the Sage external system code (i.e. what is currently in data/extcode).

There will also be no SPKGs in the new tarball. The script will have disassembled each SPKG foo-x.y.z.spkg, repacking the src/ directory into a new tarball upstream/foo-x.y.z.tar.bz2 and merging the internal Mercurial repository into the single consolidated git repo, moving it into the subdirectory packages/, specifically so that its files appear in packages/foo/.

Thus, in this variant of Sage, when installing a package, instead of extracting an SPKG file into a build directory for building, the spkg-install script / patches / etc. and the source tarball will be separately copied (resp. extracted) into the build directory. Installation of actual SPKG files will be emulated - when you run sage -i foo.spkg, the script will disassemble the SPKG as described above, and then install it in its new way.

Besides this, Sage will be generally modified to work with the new paths which all the above necessitate, or, in simple cases, to just copy the files from the new consolidated repository into their old locations whenever you run sage -b.

sagedev.py

This is a Python module which implements development tools for Sage. It provides an interface to our Trac server, an interface to git, and an interface to gathering input from the user, all of which come together to form sage dev.

Functionality includes:

  • start: Start or continue working on a given ticket.
  • save: Add/commit changes.
  • upload: Show your latest changes on the trac ticket.
  • sync: Merge changes from the latest Sage or from the latest work on another given ticket into your current code.
  • ...?

directory structure

The proposed directory structure of sage root is:

sage_root/
    sage          # the binary
    Makefile      # top level Makefile
    (configure)   # perhaps, eventually
    ...           # other standard top level files (README, etc.)
    build/
        core/     # sage's build system
        pkgs/     # install, patch, and metadata from spkgs
        ...
    src/
        sage/     # sage library, i.e. devel/sage-main/sage
        ext/      # sage_extcode
        (macapp/) # would no longer have to awkwardly be in extcode
        scripts/  # sage_scripts
        ...
    upstream/     # (stripped) tarballs of upstream sources (not tracked)
    local/        # installed binaries and compile artifacts (not tracked)
Something went wrong with that request. Please try again.