包装第三方代码

Sage项目的格言之一是不要重新发明轮子：如果一个算法已经在一个经过良好测试的库中实现，那么考虑将该库合并到Sage中。可用软件包的当前列表是的子目录 SAGE_ROOT/build/pkgs/ . 包的安装是通过位于中的bash脚本完成的 SAGE_ROOT/build/bin/sage-spkg . 此脚本通常通过以下命令调用：

[user@localhost]$ sage -i <options> <package name>...

选项可以是：

  • -f： 即使已安装相同版本，也要安装软件包

  • -s： 不要删除临时生成目录

  • -c： 安装后，运行spkg的测试套件。这将覆盖的设置 SAGE_CHECK 和 SAGE_CHECK_PACKAGES .

  • -d： 只下载软件包

断面 目录结构 描述中每个单独包的结构 SAGE_ROOT/build/pkgs . 分段 构建软件包 我们将了解如何安装和测试您或其他人编写的新spkg。最后， 新包和更新包的包含程序 解释如何提交新的包以包含在Sage源代码中。

包类型

并非所有软件包都是默认生成的，它们分为标准包、可选包和实验包：

  • 标准 默认情况下生成包。为了几个包裹， configure 检查它们在系统中是否可用，在这种情况下，将跳过这些包的生成。标准包有严格的质量要求：它们应该在所有支持的平台上工作。为了接受新的标准包，它应该在一段时间内是可选的，请参阅 新包和更新包的包含程序 .

  • 可选择的 软件包的要求是一样的，它们也应该在所有支持的平台上工作。如果有 optional doctests 在Sage库中，这些测试必须通过。请注意，可选软件包没有标准软件包测试得多，因此在实践中，它们可能比标准软件包更容易损坏。

  • 对于 实验的 包裹，门槛要低得多：即使有一些问题，包裹还是可以接受的。

包源类型

与按包类型划分正交，一个包正好有以下一种源类型：

  1. A normal 包裹：

    • 来自所需文件中命名的tarball checksums.ini 在Sage的镜子上；

    • 其版本号由所需文件定义 package-version.txt ；

    • Sage使用构建和安装脚本安装包（请参见 构建和安装普通包的脚本 ；

    • Sage在中记录使用文件安装的包的版本号 $SAGE_LOCAL/var/lib/sage/installed/ 并将重新运行安装，如果 package-version.txt 变化。

  2. A pip 包裹：

    • 直接从https://pypi.org/；

    • 要安装的版本是使用所需文件确定的 requirements.txt --在最简单的形式中，这个文件只包含包的名称（更多详细信息请参阅https://pip.pypa.io/en/stable/user-guide/#需求-文件）；

    • Sage使用 pip 包装经理；

    • Sage将已安装软件包版本号的记录委托给它；

    • 根据政策，不 standard 包允许是 pip 包裹。

  3. A script 包裹：

    • 与tarball无关；

    • 文件 package-version.txt 是可选的；

    • 安装包将运行生成和安装脚本（请参阅 构建和安装普通包的脚本 ；

    • Sage在中记录使用文件安装的包的版本号 $SAGE_LOCAL/var/lib/sage/installed/ 并将重新运行安装，如果 package-version.txt 变化。

总结一下：包源类型的确定如下：如果有文件 requirements.txt ，它是一个 pip 包裹。如果没有，那么如果 checksums.ini 文件，是的 normal 否则，它是一个 script 包裹。

目录结构

Sage中的第三方软件包由两部分组成：

  1. 由第三方分发的tarball，或者尽可能靠近它。修改tarball的有效原因是删除不必要的文件以保持下载大小可管理、重新生成自动生成的文件或在必要时更改目录结构。在某些情况下，您可能需要（另外）更改tarball的文件名。在任何情况下，实际的代码必须是未修改的：如果需要更改源代码，请添加 patch 相反。也见 改性柏油球 用于自动修改上游tarball。

  2. 生成脚本和相关文件位于子目录中 SAGE_ROOT/build/pkgs/<package> ，替换位置 <package> 上游项目名称的小写版本。如果项目名称包含非字母数字且不是下划线的字符，则应删除这些字符或将其替换为下划线。例如，项目 FFLAS-FFPACK 被称为 fflas_ffpack 在Sage和 path.py 已重命名 pathpy 在萨奇。

作为一个例子，让我们考虑一个假设的FoO项目。他们（上游）分发一个tarball FoO-1.3.tar.gz （将自动放入 SAGE_ROOT/upstream 在安装过程中）。要将其打包到Sage中，我们将创建一个子目录，其中至少包含以下文件：

SAGE_ROOT/build/pkgs/foo
|-- checksums.ini
|-- dependencies
|-- package-version.txt
|-- spkg-install.in
|-- SPKG.txt
`-- type

以下是一些可以添加的附加文件：

SAGE_ROOT/build/pkgs/foo
|-- patches
|   |-- bar.patch
|   `-- baz.patch
|-- spkg-check.in
`-- spkg-src

我们将在下面几节讨论各个文件。

包装类型

文件 type 应该包含一个单词 standard ， optional 或 experimental . 见 包类型 了解这些类型的含义。

构建和安装普通包的脚本

这个 spkg-build.in 和 spkg-install.in 文件是的模板 bash 脚本 spkg-build 和 spkg-install ，生成和/或安装包。

这个 *.in 脚本模板应该 not 以shebang行作为前缀 (#!... )并且不应在其权限中设置可执行位。这些是在生成脚本时自动添加的，并在安装包时添加一些附加的样板文件。

这个 spkg-build.in 和 spkg-install.in Sage源代码树中的文件只需要关注构建和安装该包的特定步骤。如果没有 spkg-build.in 存在，然后 spkg-install.in 负责这两个步骤，但鼓励尽可能将它们分开。

也可以包含名为 spkg-preinst.in 或 spkg-postinst.in 在将包安装到中之前或之后运行其他步骤 $SAGE_LOCAL . 建议将修改已安装文件的步骤放在单独的 spkg-postinst.in 编写模板而不是将它们与 spkg-install.in . 这是因为 :trac:`24106` ， spkg-install 不一定要将包直接安装到 $SAGE_LOCAL . 但是，到那时 spkg-postinst 正在运行，安装到 $SAGE_LOCAL 是完整的。

在最好的情况下，上游项目可以简单地通过通常的configure/make/makeinstall步骤进行安装。在这种情况下 spkg-build.in 脚本模板包括：

cd src
sdh_configure
sdh_make

见 帮助程序函数 有关helper函数的更多信息 sdh_configure ， sdh_make 等。

这个 spkg-install.in 脚本模板包括：

cd src
sdh_make_install

注意，tarball中的顶级目录被重命名为 src 在呼叫 spkg-build 和 spkg-install 脚本，这样你就可以使用 cd src 而不是 cd foo-1.3 .

是否包含任何有意义的文档但未由安装 sdh_make_install （这叫什么 make install )，然后您可以添加类似以下内容来安装它：

if [ "$SAGE_SPKG_INSTALL_DOCS" = yes ] ; then
    sdh_make doc
    sdh_install doc/ "$SAGE_SHARE"/doc/PACKAGE_NAME
fi

注解

在sage9.1之前，脚本模板被调用 spkg-build ， spkg-install 等等，不带分机 .in .

在sage8.1之前，包含了shebang行，脚本被标记为可执行的。然而，到目前为止，情况已不再如此 :trac:`23179` . 现在，源代码树中的脚本是故意编写的而不是直接执行的，只有当它们被复制到包的构建目录中时，才会被制作成可执行脚本。

构建/安装脚本仍然可以用Python编写，但是Python代码应该放在一个单独的文件中（例如。 spkg-install.py )，然后可以从真实世界执行 spkg-install.in 像：

exec sage-system-python spkg-install.py

或

exec sage-python23 spkg-install.py

更详细地说： sage-system-python 运行计算机上预装的Python版本。如果在Sage构建自己的Python之前安装了包，请使用此选项。 sage-python23 运行Sage构建的Python版本（python2或python3），具体取决于构建的配置方式；如果要安装Python包，则应使用此脚本，以确保库安装在正确的位置。

顺便说一下，还有一个剧本 sage-python . 这应该在运行时使用，例如在中的脚本中 SAGE_LOCAL/bin 他们期望Sage的Python已经被建造出来了。

许多软件包目前没有将构建和安装步骤分开，只提供一个 spkg-install.in 文件，两者兼而有之。这种分离特别适用于根拥有的安装层次结构，其中类似于 sudo 必须用于安装文件。为此，Sage使用了一个环境变量 $SAGE_SUDO ，它的值可以由开发人员在构建时提供，它应该针对特定的系统 sudo -喜欢命令（如果有的话）。然后遵守以下规则：

  • 如果 spkg-build.in 存在，生成的脚本 spkg-build 首先调用，然后是 $SAGE_SUDO spkg-install .

  • 否则，只有 spkg-install 被称为（无 $SAGE_SUDO ). 这样的包应该在中的所有命令前面加前缀 spkg-install.in 写入安装层次结构的 $SAGE_SUDO .

安装脚本包的脚本

一个脚本包有一个名为 spkg-install . 它需要是一个可执行的shell脚本；它不受上一节中描述的模板的约束。

Sage跑步 spkg-install 从 $SAGE_ROOT 通过获取文件而获得的环境中的目录 src/bin/sage-env 和 build/bin/sage-build-env-config .

帮助程序函数

在 spkg-build ， spkg-install 和 spkg-check 脚本，以下函数可用。它们在文件中定义 $SAGE_ROOT/build/bin/sage-dist-helpers ，如果您想查看源代码。它们应该用于确保设置了适当的变量，并避免代码重复。这些函数名以 sdh_ ，代表“Sage distribution helper”。

  • sdh_die MESSAGE ：退出生成脚本，如果上一个命令的错误代码为非零，则返回1，然后打印错误消息。这通常用于：

    command || sdh_die "Command failed"

    此函数还可以（如果没有提供任何参数）从stdin读取错误消息。特别是，它与heredoc结合使用，可以编写多行错误消息：

    command || sdh_die << _EOF_
Command failed.
Reason given.
_EOF_

    注解

    其他helper函数调用 sdh_die ，所以不要使用（例如） sdh_make || sdh_die ：之后的部分 || 永远无法到达。

  • sdh_check_vars [VARIABLE ...] ：检查一个或多个变量是否已定义且非空，如果有未定义或为空，则返回错误。变量名应不带“$”以防止不必要的扩展。

  • sdh_configure [...] ：运行 ./configure 带着论据 --prefix="$SAGE_LOCAL" ， --libdir="$SAGE_LOCAL/lib" ， --disable-maintainer-mode 和 --disable-dependency-tracking . 附加参数 ./configure 可以作为论据。

  • sdh_make [...] ：运行 $MAKE 默认目标。

    附加参数 $MAKE 可以作为论据。

  • sdh_make_install [...] ：运行 $MAKE install 使用DESTDIR

    对于分段安装，正确设置为临时安装目录。附加参数 $MAKE 可以作为论据。如果 $SAGE_DESTDIR 未设置，则命令将与一起运行 $SAGE_SUDO ，如果已设置。

  • sdh_pip_install [...] ：运行 pip install 用给定的

    参数，以及用于使用pip将包安装到Sage中的其他默认参数。目前这只是一个包装 sage-pip-install 命令。如果 $SAGE_DESTDIR 未设置，则命令将与一起运行 $SAGE_SUDO ，如果已设置。

  • sdh_install [-T] SRC [SRC...] DEST ：复制一个或多个文件或

    目录作为 SRC （对于目录，递归地）放入目标目录 DEST ，同时确保 DEST 它的所有父目录都存在。 DEST 应该是一条小路 $SAGE_LOCAL ，一般来说。为 DESTDIR 安装 $SAGE_DESTDIR 路径将自动添加到目标。

    这个 -T 期权待遇 DEST 改为普通文件（例如，将文件复制到不同的文件名）。在这种情况下，仍然会创建所有目录组件。

以下内容会自动添加到每个安装脚本中，因此您不必自己添加它。

  • sdh_guard ：的包装 sdh_check_vars 这检查了一些

    没有公共变量，许多/大多数包将无法正确构建 (SAGE_ROOT ， SAGE_LOCAL ， SAGE_SHARE ). 这对于防止安装到意外位置非常重要。

以下也有，但很少使用。

  • sdh_cmake [...] ：运行 cmake 在当前目录中

    给定的参数以及传递给cmake的其他参数（假设包使用GNUInstallDirs模块），以便 CMAKE_INSTALL_PREFIX 和 CMAKE_INSTALL_LIBDIR 设置正确。

  • sdh_preload_lib EXECUTABLE SONAME ：（仅限Linux—其他系统上没有操作

    平台。）检查由加载的共享库 EXECUTABLE （可能是一个程序或另一个库）对于以 SONAME ，以及如果找到的话 SONAME 到 LD_PRELOAD 环境变量。看到了吗 :trac:`24885` .

自检

这个 spkg-check.in 文件是一个可选的脚本模板，但强烈建议使用该模板来运行包的自检。的格式 spkg-check 是一样的 spkg-build 和 spkg-install . 如果 SAGE_CHECK 环境变量已设置，请参阅Sage安装指南。理想情况下，上游有某种类型的测试套件，可以与标准一起运行 make check 目标。在这种情况下 spkg-check.in 脚本模板只包含：

cd src
$MAKE check

基于Python的包

安装基于Python的包的最佳方法是使用pip，在这种情况下 spkg-install.in 脚本模板可能只包含

cd src && sdh_pip_install .

Where sdh_pip_install is a function provided by sage-dist-helpers that points to the correct pip for the Python used by Sage, and includes some default flags needed for correct installation into Sage.

如果pip不能工作但是命令 python setup.py install 威尔，那么 spkg-install.in 脚本模板应该调用 sage-python23 而不是 python . 这将确保使用正确版本的Python构建和安装包。同样适用于 spkg-check.in 脚本模板；例如 scipy spkg-check.in 文件包含行

exec sage-python23 spkg-check.py

这个SPKG.txt文件文件

这个 SPKG.txt 文件应遵循以下模式：

= PACKAGE_NAME =

== Description ==

What does the package do?

== License ==

What is the license? If non-standard, is it GPLv3+ compatible?

== Upstream Contact ==

Provide information for upstream contact.

== Dependencies ==

Put a bulleted list of dependencies here:

* python
* readline

== Special Update/Build Instructions ==

If the tarball was modified by hand and not via a spkg-src
script, describe what was changed.

具有 PACKAGE_NAME 替换为包名称。遗产 SPKG.txt 文件有一个额外的changelog部分，但是这个信息现在保存在git存储库中。

包依赖项

许多包依赖于其他包。例如考虑 eclib 椭圆曲线封装。这个软件包使用PARI、NTL和FLINT库。下面是 dependencies 文件供 eclib ：

pari ntl flint

----------
All lines of this file are ignored except the first.
It is copied by SAGE_ROOT/build/make/install into SAGE_ROOT/build/make/Makefile.

对于Python包，常见的依赖项包括 pip ， setuptools 和 future . 如果您的软件包依赖于其中任何一个，请使用 $(PYTHON_TOOLCHAIN) 相反。例如，这里是 dependencies 文件供 configparser ：：

.. CODE-BLOCK:: text

$（PYTHON）|$（PYTHON_工具链）

（参见下文了解 | ）

如果没有依赖项，则可以使用

# no dependencies

----------
All lines of this file are ignored except the first.
It is copied by SAGE_ROOT/build/make/install into SAGE_ROOT/build/make/Makefile.

实际上有两种依赖关系：一种是普通依赖关系，另一种是顺序依赖关系，这两种依赖关系较弱。的语法 dependencies 文件是

normal dependencies | order-only dependencies

如果没有 | ，则所有依赖关系都正常。

  • 如果A包有 order-only dependency 在B上，它只是意味着必须先构建B，然后才能构建A。B的版本无关紧要，只在乎安装了B这一事实。如果依赖项纯粹是一个构建时依赖项（例如，对pip的依赖仅仅是因为 spkg-install 文件使用pip）。

  • 如果A有 正常依赖关系 在B上，这意味着每次更新B时都应该重新构建A。这是最常见的依赖。库需要一个正常的依赖关系：如果我们升级NTL，我们应该重建使用NTL的所有东西。

为了检查包的依赖项是否正确，以下命令应该可以正常工作：

[user@localhost]$ make distclean && make base && make PACKAGE_NAME

最后，请注意，标准包应该只依赖于标准包，可选包应该只依赖于标准包或可选包。

修补源

对源代码的实际更改必须通过修补程序进行，这些补丁程序应该放在 patches/ 目录，并且必须具有 .patch 扩展。GNU补丁是与Sage一起发布的，因此您可以依赖它的可用性。修补程序必须在其标头中包含文档（在第一个diff hunk之前），并且路径中必须只有一个“prefix”级别（即，在被修补的上游源的根之上只有一个路径级别）。因此，典型的修补程序文件应该如下所示：

Add autodoc_builtin_argspec config option

Following the title line you can add a multi-line description of
what the patch does, where you got it from if you did not write it
yourself, if they are platform specific, if they should be pushed
upstream, etc...

diff -dru Sphinx-1.2.2/sphinx/ext/autodoc.py.orig Sphinx-1.2.2/sphinx/ext/autodoc.py
--- Sphinx-1.2.2/sphinx/ext/autodoc.py.orig  2014-03-02 20:38:09.000000000 +1300
+++ Sphinx-1.2.2/sphinx/ext/autodoc.py  2014-10-19 23:02:09.000000000 +1300
@@ -1452,6 +1462,7 @@

     app.add_config_value('autoclass_content', 'class', True)
     app.add_config_value('autodoc_member_order', 'alphabetic', True)
+    app.add_config_value('autodoc_builtin_argspec', None, True)
     app.add_config_value('autodoc_default_flags', [], True)
     app.add_config_value('autodoc_docstring_signature', True, True)
     app.add_event('autodoc-process-docstring')

直接在 patches/ 在运行 spkg-install 脚本（只要他们有 .patch 扩展）。如果需要有条件地应用修补程序（例如仅在特定平台上），可以将这些修补程序放置在 patches/ 并使用 sage-apply-patches 脚本。例如，考虑到布局：

SAGE_ROOT/build/pkgs/foo
|-- patches
|   |-- solaris
|   |   |-- solaris.patch
|   |-- bar.patch
|   `-- baz.patch

补丁 bar.patch 和 baz.patch 应用于中未打包的上游源 src/ 赛前 spkg-install . Solaris有条件地应用修补程序 spkg-install 应该包含这样的节：

if [ $UNAME == "SunOS" ]; then
    sage-apply-patches -d solaris
fi

何处 -d 标志应用 solaris/ 主目录的子目录 patches/ 目录。

何时修补、何时重新打包、何时自动分配

  • 尽可能使用未匹配的原始上游tarball。

    有时你似乎需要修补（手写） Makefile 因为它“硬编码”某些路径或编译器标志：

    --- a/Makefile
+++ b/Makefile
@@ -77,7 +77,7 @@
 # This is a Makefile.
 # Handwritten.

-DESTDIR = /usr/local
+DESTDIR = $(SAGE_ROOT)/local
 BINDIR   = $(DESTDIR)/bin
 INCDIR   = $(DESTDIR)/include
 LIBDIR   = $(DESTDIR)/lib

    别打补丁了。可以从命令行重写Makefile变量。只需在 spkg-install ：

    $(MAKE) DESTDIR="$SAGE_ROOT/local"

  • 检查Debian或其他发行版是否已经为上游提供了修补程序。使用它们，不要重新发明轮子。

  • 如果上游Makefile没有构建共享库，就不用费心去修补它了。

    自动分配包，并使用Automake和Libtool的标准工具。这确保了共享库构建在Linux和macOS之间是可移植的。

  • 如果你必须对 configure.ac 或者“自动工具”生成系统的其他源文件（或者如果要自动配置包），则不能使用修补程序；将 modified tarball 相反。

  • 如果修补程序很大，就不要使用修补程序。使 modified tarball 相反。

  • 否则， maintain a set of patches .

如何维护一组补丁

我们建议使用以下工作流来维护一组修补程序。

  • 分叉包并将其放到公共git存储库中。

    如果上游有一个公共版本控制存储库，请从那里导入它。如果上游没有公共版本控制存储库，请从上游tarball导入当前源。我们打电话给分公司吧 upstream .

  • 为Sage所需的更改创建一个分支，我们称之为 sage_package_VERSION 在哪里 version 是上游版本号。

  • 进行更改并提交给分支机构。

  • 生成针对 upstream 分支机构：

    rm -Rf SAGE_ROOT/build/pkgs/PACKAGE/patches
mkdir SAGE_ROOT/build/pkgs/PACKAGE/patches
git format-patch -o SAGE_ROOT/build/pkgs/PACKAGE/patches/ upstream

  • （可选）创建 spkg-src Sage包目录中的文件，该文件使用上述命令重新生成修补程序目录。

  • 当新的上游版本可用时，将其合并（或导入）到 upstream ，然后创建一个新的分支，并在更新的上游上重新建立基：

    git checkout sage_package_OLDVERSION
git checkout -b sage_package_NEWVERSION
git rebase upstream

    然后重新生成补丁。

改性柏油球

这个 spkg-src 文件是可选的，仅用于记录上游tarball是如何更改的。理想情况下，它没有被修改，那么就没有了 spkg-src 文件也存在。

但是，如果您确实必须修改上游tarball，那么建议您编写一个名为 spkg-src ，进行更改。这不仅可以作为文档，而且可以更容易地将相同的修改应用到将来的版本中。

包版本控制

这个 package-version.txt 文件只包含版本。如果上游是 FoO-1.3.tar.gz 那么包版本文件将只包含 1.3 .

如果上游软件包来自稳定版本以外的某个版本，或者上游没有版本号，则应使用修订的日期。例如 database_stein_watkins 带版本的包 20110713 包含截至2011年7月13日的数据库。注意，日期应该是指 内容 直到它被包装成Sage的那一天。这个特别的Sage包 database_stein_watkins 创建于2014年，但其中包含的数据最近一次更新是在2011年。

如果应用任何修补程序，或对上游tarball进行了更改（请参见 目录结构 对于允许的更改），则应附加一个 .p0 以表明它不是一个普通的包。

此外，无论何时对包进行更改 没有 更改上游tarball（例如，您添加了一个额外的补丁或修复了 spkg-install 文件），您还应该添加或增加修补程序级别。所以不同的版本 1.3 ， 1.3.p0 ， 1.3.p1 , ... 版本号或修补程序级别的更改将触发软件包的重新安装，以便将更改考虑在内。

校验和

这个 checksums.ini 文件包含上游tarball的文件名模式（没有实际版本）及其校验和。如果上游是 $SAGE_ROOT/upstream/FoO-1.3.tar.gz ，创建新文件 $SAGE_ROOT/build/pkgs/foo/checksums.ini 仅包含：

tarball=FoO-VERSION.tar.gz

Sage内部替换 VERSION 包含以下内容的子字符串 package-version.txt . 要重新计算校验和，请运行：

[user@localhost]$ sage --package fix-checksum foo

这将修改 checksums.ini 用正确的校验和归档。

创建包的实用程序脚本

假设你已经下载了 $SAGE_ROOT/upstream/FoO-1.3.tar.gz 您可以使用：

[user@localhost]$ sage --package create foo --version 1.3 --tarball FoO-VERSION.tar.gz --type experimental

创造 $SAGE_ROOT/build/pkgs/foo/package-version.txt ， checksums.ini 和 type 一步到位。

构建软件包

在这个阶段，你有一个新的tarball，它还没有与Sage一起分发 (FoO-1.3.tar.gz 在节的示例中 目录结构 ). 现在您需要手动将其放入 SAGE_ROOT/upstream/ 目录和运行 sage --fix-pkg-checksums 如果你还没有那么做。

现在可以使用以下命令安装程序包：

[user@localhost]$ sage -i package_name

或：

[user@localhost]$ sage -f package_name

强制重新安装。如果您的软件包包含 spkg-check 脚本（请参见 自检 )可以跑了：

[user@localhost]$ sage -i -c package_name

或：

[user@localhost]$ sage -f -c package_name

如果一切顺利的话，打开一个罚单，在罚单中放一个指向原始tarball的链接，然后上传一个带有代码的分支 SAGE_ROOT/build/pkgs .

新包和更新包的包含程序

不属于Sage的包将首先成为可选的或试验性的（如果它们不能在所有支持的系统上构建，则是后者）。在他们已经在可选的一段时间没有问题后，他们可以被建议作为标准包纳入Sage。

若要提出可选/实验包，请在相应的 Component: 字段设置为 packages:experimental 或 packages:optional . 相关的代码要求在下面的章节中描述。

在检票并包括之后，可选套餐至少要保持一年的状态，之后可以建议将其作为标准套餐纳入Sage。为此，使用 Component: 字段设置为 packages:standard . 然后在谷歌小组里提出一个建议 sage-devel .

升级包到新的上游版本或附加补丁包括打开相应类别的问题，如上所述。

许可证信息

如果您正在修补一个标准的Sage spkg，那么您应该确保该软件包的许可证信息是最新的，并且在其 SPKG.txt 文件和文件中 SAGE_ROOT/COPYING.txt . 例如，如果您正在生成一个spkg，它将vanilla源代码升级到新版本，请检查许可证是否在不同版本之间更改。

新标准包的先决条件

要使包装成为Sage标准分发的一部分，它必须满足以下要求：

  • 许可 . 对于标准软件包，许可证必须与GNU通用公共许可证版本3兼容。自由软件基金会有一长串 licenses and comments about them .

  • 建立支持 . 代码必须构建在所有完全支持的平台（Linux、macOS、Cygwin）上；请参阅 多平台测试 .

  • 质量 . 代码应该比任何其他可用的代码（通过上述两个标准）要“更好”，作者需要证明这一点。应该对Python和其他软件进行比较。通过质量测试的标准包括：

    • 速度

    • 文档

    • 可用性

    • 没有内存泄漏

    • 可维护

    • 便携性

    • 合理的构建时间、大小、依赖关系

  • 以前是可选程序包 . 一个新的标准包必须作为可选包花费了一些时间。或者有一个很好的理由说明这是不可能的。

  • 裁判 . 如中所述，必须对代码进行引用 Sage-Trac服务器 .