Дорожная карта инструментария#

Использование библиотеки SciPy требует (или опционально зависит от) нескольких других библиотек для работы, основными зависимостями являются Python и NumPy. Для сборки библиотеки или документации требуется большая коллекция библиотек и инструментов.

Конечно, сами инструменты и библиотеки не статичны. Этот документ призван предоставить руководство по тому, как использование SciPy этих динамических зависимостей будет развиваться со временем.

SciPy стремится быть совместимым с несколькими версиями своих зависимых библиотек и инструментов. Принуждение пользователей обновлять другие компоненты при каждом выпуске значительно снизило бы ценность SciPy. Однако поддержание обратной совместимости с очень старыми инструментами/библиотеками накладывает ограничения на то, какие новые функциональные возможности и возможности могут быть включены. SciPy придерживается несколько консервативного подхода, поддерживая совместимость с несколькими основными выпусками Python и NumPy на основных платформах. (Это само по себе может налагать дополнительные ограничения. См. раздел C Compilers для примера.)

Прежде всего, SciPy — это проект на Python, поэтому для него требуется среда Python.
Необходимо установить числовые библиотеки BLAS и LAPACK.
Требуются компиляторы для кода C, C++, Fortran, а также для Cython и Pythran (последний в настоящее время можно отключить)
В среде Python требуется numpy пакет для установки.
Тестирование требует pytest и hypothesis Пакеты Python.
Для сборки документации требуется matplotlib, Sphinx и MyST-NB пакеты вместе с темой PyData.

Инструменты, используемые для сборки CPython, имеют последствия для инструментов, используемых при сборке SciPy. Это также влияет на примеры, используемые в документации (например, строки документации функций), поскольку эти примеры могут использовать только функциональность, присутствующую во всех поддерживаемых конфигурациях.

Сборка SciPy#

Версии Python#

SciPy совместим с несколькими версиями Python. При отказе от поддержки старых версий Python, SciPy руководствуется [NEP29]. В целом, поддержка самой старой версии Python прекращается через 42 месяца после первоначального релиза. После принятия PEP 602 это обычно происходит в апреле и подхватывается релизом SciPy в середине года.

Поддержка версий Python с течением времени

Поддержка Python 2.7 была прекращена начиная с SciPy 1.3.

Дата	Поддерживаемые версии Python
2025	Py3.11+
2024	Py3.10+
2023	Py3.9+
2022	Py3.8+
2021	Py3.7+
2020	Py3.6+
2019	Py3.5+
2018	Py2.7, Py3.4+

NumPy#

SciPy зависит от NumPy, но релизы SciPy не привязаны к релизам NumPy. SciPy стремится быть совместимым как минимум с 4 предыдущими релизами NumPy. В частности, SciPy не может полагаться на функции только последнего NumPy, а должен быть написан с использованием того, что является общим для всех этих 4 Релизы NumPy.

Поддержка версий Python и NumPy для каждой версии SciPy

Таблица показывает версии NumPy и Python, подходящие для каждой минорной версии SciPy. Обратите внимание, что не все патч-версии для конкретной минорной версии SciPy поддерживают все перечисленные версии Python. Только самая последняя патч-версия в каждой минорной версии гарантированно поддерживает все перечисленные версии Python.

Версия SciPy	Версии Python	Версии NumPy
1.15	>=3.10, <3.14	>=1.23.5, <2.5.0
1.14	>=3.10, <3.14	>=1.23.5, <2.3.0
1.13	>=3.9, <3.13	>=1.22.4, <2.3.0
1.12	>=3.9, <3.13	>=1.22.4, <2.0.0
1.11	>=3.9, <3.13	>=1.21.6, <1.27.0
1.10	>=3.8, <3.12	>=1.19.5, <1.26.0
1.9	>=3.8, <3.12	>=1.18.5, <1.26.0
1.8	>=3.8, <3.11	>=1.17.3, <1.24.0
1.7	>=3.7, <3.11	>=1.16.5, <1.23.0
1.6	>=3.7, <3.10	>=1.16.5, <1.21.0
1.5	>=3.6, <3.10	>=1.14.5, <1.20.0
1.4	>=3.5, <3.9	>=1.13.3, <1.18.0
1.2	2.7, >=3.4, <3.8	>=1.8.2, <1.17.0

В конкретных случаях, например, для определённой архитектуры, эти требования могут отличаться. Пожалуйста, проверьте примечания к выпуску и мета-пакет oldest-supported-numpy для дополнительной информации [OSN].

Компиляторы#

Сборка SciPy требует компиляторов для C, C++, Fortran, а также транспайлеров Python Cython и Pythran (последний является опциональной зависимостью начиная с версии 1.7.0).

Для поддержания совместимости с большим количеством платформ и настроек, особенно где использование официальных сборок (или других каналов распространения, таких как Anaconda или conda-forge) невозможно, SciPy старается сохранять совместимость со старыми компиляторами на платформах, которые ещё не достигли официального конца жизненного цикла.

Как подробнее объяснено ниже, текущие минимальные версии компиляторов:

Компилятор	Платформа по умолчанию (протестировано)	Вторичная платформа (не тестировалась)	Минимальная версия
GCC	Linux	AIX, Alpine Linux, OSX	GCC 9.x
LLVM	OSX	Linux, FreeBSD, Windows	LLVM 12.x
MSVC	Windows		Visual Studio 2019 (vc142)

Обратите внимание, что в настоящее время нет выделенной задачи CI для тестирования минимальной поддерживаемой версии LLVM/Clang. Более старые версии, чем используемые в CI SciPy, должны работать, если они поддерживают базовый (не stdlib) C++17. Пожалуйста, создайте issue, если вы столкнетесь с проблемой во время компиляции.

Официальные сборки#

В настоящее время сборки SciPy создаются следующим образом:

Платформа	CI База Изображения	Компиляторы	Комментарий
Linux x86	`ubuntu-22.04`	GCC 10.2.1	`cibuildwheel`
Linux arm	`docker-builder-arm64`	GCC 11.3.0	`cibuildwheel`
OSX x86_64 (OpenBLAS)	`macos-12`	Apple clang 13.1.6/gfortran 11.3.0	`cibuildwheel`
OSX x86_64 (Accelerate)	`macos-13`	Apple clang 15.0.0/gfortran 13.2.0	`cibuildwheel`
OSX arm64 (OpenBLAS)	`macos-14`	Apple clang 15.0.0/gfortran 12.1.0	`cibuildwheel`
OSX arm64 (Accelerate)	`macos-14`	Apple clang 15.0.0/gfortran 13.2.0	`cibuildwheel`
Windows	`windows-2019`	GCC 10.3.0 (rtools)	`cibuildwheel`

Обратите внимание, что колеса OSX дополнительно включают gfortran 11.3.0 для x86_64, и gfortran 12.1.0 для arm64. См. tools/wheels/cibw_before_build_macos.sh.

C Compilers#

SciPy совместим с большинством современных компиляторов C (в частности clang). В настоящее время существует разумная поддержка последних стандартов языка C во всех соответствующих компиляторах, хотя это сильно отличается от того, как было раньше. Следующие абзацы в основном обсуждают эволюцию этих ограничений; читатели, которых не интересует исторический контекст, могут перейти к таблице в конце.

Historical context around ABI vs. compiler support vs. C standards

В прошлом наиболее ограничивающим компилятором на соответствующих платформах с точки зрения поддержки C был компилятор Microsoft Visual C++ и набор инструментов (вместе известные как MSVC; он имеет сложную схема версионирования) [MSVC]. До Visual Studio 2013 каждая версия MSVC поставлялась с обновленной библиотекой C Runtime (CRT), несовместимой с предыдущими.

Эта несовместимость двоичного интерфейса приложений (ABI) означала, что все проекты, желающие взаимодействовать через этот интерфейс (например, вызывать функцию из общей библиотеки), должны были быть (пере)скомпилированы с той же версией MSVC. Длительная поддержка CPython 2.7 означала, что сам Python долгое время был застрял на VS 2008 (чтобы не нарушить ABI в патч-релизах), и, следовательно, SciPy также был застрял на этой версии.

Использование VS 2008 (которая не поддерживает C99) для компиляции сборок под CPython 2.7 означало, что в течение долгого времени код на C в SciPy должен был соответствовать более раннему стандарту C90 для языка и стандартной библиотеки. После прекращения поддержки CPython 2.7 в SciPy 1.3.x это ограничение наконец было снято (хотя сначала постепенно).

С введением 'Universal C Runtime' [UCRT] поскольку с выпуском Visual Studio 2015 ABI C Runtime стал стабильным, что означает, что ограничение необходимости использования той же версии компилятора для SciPy, что и для базовой версии CPython, больше не применимо. Эта стабильность не бесконечна: Microsoft планирует выпуск с нарушением ABI - через компилятор и/или стандартные библиотеки C/C++ - (предварительно называемый "vNext») довольно долго, но пока неясно, когда это произойдёт. Как только это случится, SciPy снова будет ограничен максимум последней ABI-совместимой версией Visual Studio (в настоящее время VS 2022), пока все версии CPython, поддерживаемые согласно NEP29, не будут собраны вышестоящими разработчиками с компиляторами, совместимыми с vNext.

Более конкретно, существует различие между версией Microsoft Visual Studio и версией целевой "набор инструментов”, который определяется как «Компилятор Microsoft C++, компоновщик, стандартные библиотеки и связанные утилиты». Каждая версия Visual Studio поставляется с версией набора инструментов MSVC по умолчанию (например, VS2017 с vc141, VS2019 с vc142), но можно использовать более старые наборы инструментов даже в новых версиях Visual Studio. Из-за природы компиляторов (т.е. разделения на фронтенд и бэкенд) зависит, является ли ограничивающим фактором для поддержки определённой функции (например, в C) версия Visual Studio или набор инструментов, но в целом последнее является более серьёзным барьером и, следовательно, эффективной нижней границей.

Это связано с тем, что хотя ABI остается совместимым между версиями набора инструментов (до vNext), все операции связывания должны использовать набор инструментов не менее новой версии, чем тот, который использовался для сборки любого из задействованных артефактов, что означает, что обновления версий набора инструментов имеют тенденцию быть "заразными", как в: требовать от всех использующих библиотек также обновить версию своего набора инструментов (и, вероятно, компилятора). Это больше проблема для NumPy, чем для SciPy, поскольку последний имеет небольшой C API и компилируется гораздо меньшим количеством проектов, чем NumPy. Кроме того, использование более нового набора инструментов означает, что пользователям библиотек, которые компилируют код C++ (как это делает SciPy), также может потребоваться более новая версия Microsoft Visual C++ Распространяемый, который, возможно, придётся распределить между ними.

Подводя итог, минимальное требование к компилятору MSVC или набору инструментов для каждой версии SciPy определялось в основном самой старой поддерживаемой версией CPython на тот момент. Первой версией SciPy, которая повысила минимальное требование сверх этого, была SciPy 1.9, из-за включения подмодуля HiGHS, который не компилируется с vc141 (и агрессивного удаления VS2017 в публичном CI, что сделало невозможным обеспечение работы всего везде с нестандартными версиями набора инструментов).

Версия SciPy	Поддержка CPython	MS Visual C++	Версия набора инструментов
До версии 1.2	2.7 & 3.4+	VS 2008 (9.0)	vc90
1.3, 1.4	3.5+	VS 2010 (10.0)	vc100
1.5	3.6+	VS 2015 (14.0)	vc140
1.6, 1.7	3.7+	VS 2017 (14.1)	vc141
1.8	3.8+	VS 2017 (14.1)	vc141
1.9	3.8+	VS 2019 (14.20)	vc142

С точки зрения стандартов языка C, важно отметить, что C11 имеет дополнительные возможности (например, атомарные операции, многопоточность), некоторые из которых (VLAs и комплексные типы) были обязательными в стандарте C99. C17 (иногда называемый C18) можно рассматривать как исправление ошибок для C11, поэтому в целом C11 можно полностью пропустить.

Использование более продвинутых языковых функций в SciPy было ограничено доступной поддержкой компилятора, и Microsoft в частности очень долго добивалась соответствия C99/C11/C17, однако начиная с Visual Studio 16.8, C11/C17 поддерживается (хотя без опциональных функций C11). C99 поддержка было бы особенно интересно для SciPy. Однако все еще возможно использовать комплексные типы в Windows, при условии что windows-specific типы используются.

Поэтому использование функций C, выходящих за рамки C90, было возможно только в той мере, в какой была поддержка в Windows; однако, по состоянию на конец 2021 года, используется достаточно новый компилятор. Это связано с тем, что GCC и LLVM поддерживают все соответствующие функции C11 в самых старых используемых версиях, а C17 — это просто исправление ошибок для C11, как упоминалось выше. Короче говоря:

Дата	C Standard
<= 2018	C90
2019	C90 для старого кода, можно рассмотреть C99 для нового
2020	C99 (нет , , & VLAs)
2021	C17 (нет , , & VLAs)
?	C23, , , …

Стандарты языка C++#

Стандарты языка C++ для SciPy обычно являются рекомендациями, а не официальными решениями. Это особенно верно для попыток предсказать сроки внедрения новых стандартов.

Дата	Стандарт C++
<= 2019	C++03
2020	C++11
2021	C++14
2022	C++17 (базовый язык + общедоступные функции стандартной библиотеки)
?	C++17 (с полной stdlib), C++20, C++23, C++26

Исторический контекст ограничений компилятора из-за manylinux

После прекращения поддержки Python 2.7, C++11 можно использовать повсеместно, а после прекращения поддержки Python 3.6, версия Visual Studio (которая ранее была застряла на 14.0 из-за совместимости ABI с CPython) стала достаточно новой, чтобы поддерживать даже C++17.

Поскольку официальные сборки (см. выше) используют довольно свежую версию LLVM, узким местом для поддержки C++ является самая старая поддерживаемая версия GCC, где SciPy ограничена в основном версией в самых старых поддерживаемых версиях manylinux и образах [МНОГО].

В конце 2021 года (с окончательным удалением manylinux1 wheels), минимальное требование к GCC изменилось на 6.3, который имеет полную поддержку C++14 [CPP]. Это соответствовало самой низкой версии GCC в соответствующих версиях manylinux, хотя это всё ещё учитывало «выброс» на основе Debian manylinux_2_24, что — в отличие от предыдущих образов manylinux, основанных на производном от RHEL CentOS, которые могли использовать обратно совместимые бэкпорты GCC в «RHEL Dev Toolset», — застряло с GCC 6.3. Этот образ не прижился не в последнюю очередь из-за этих устаревшие компиляторы и достиг конца жизненного цикла в середине 2022 года. По разным причинам, manylinux2010 также достиг своего EOL примерно в одновременно.

Оставшиеся изображения manylinux2014 и manylinux_2_28 в настоящее время поддерживают GCC 10 и 12 соответственно. Последний будет продолжать получать обновления по мере появления новых версий GCC в виде бэкпортов, но первый, вероятно, не изменится, поскольку проект CentOS больше не реагирует на публикацию aarch64 обратные порты GCC 11.

Это охватывает все основные платформы и их компиляторы с относительно недавними версиями. Однако SciPy исторически также стремился поддерживать менее распространённые платформы — если не бинарными артефактами (т.е. wheels), то хотя бы оставаясь компилируемым из исходного кода — что включает, например, AIX, Alpine Linux и FreeBSD.

Все текущие минимально поддерживаемые версии компиляторов (GCC 9, LLVM 14, VS2019 с vc142) имеют полную поддержку C++17 основной язык, который, следовательно, можно использовать безусловно. Однако, по состоянию на середину 2024 года, поддержка всей стандартной библиотеки C++17 еще не завершена во всех компиляторах [CPP], особенно LLVM. Поэтому необходимо проверять, поддерживается ли данная функция стандартной библиотеки всеми компиляторами, прежде чем её можно будет использовать в SciPy.

Поддержка C++20 стабилизируется очень медленно, даже помимо модулей, сопрограмм и нескольких функций стандартной библиотеки, которые еще не поддерживаются повсеместно. Учитывая, насколько крупным выпуском был стандарт C++20, ожидается, что это займет в то время как прежде чем мы сможем начать рассматривать перемещение нашей базовой линии. Поддержка компилятором C++23 и C++26 все еще находится в активной разработке [CPP].

Компиляторы Fortran#

В целом, любой хорошо поддерживаемый компилятор, вероятно, подходит и может быть использован для сборки SciPy. Тем не менее, мы не тестируем со старыми gfortran версий, поэтому мы сопоставляем нижнюю границу с той, что для GCC выше.

Инструмент	Версия
gfortran	>= 9.x
ifort/ifx	Недавняя версия (не тестируется в CI)
flang (LLVM)	>= 17.x

Cython & Pythran#

SciPy всегда требует свежий компилятор Cython. Начиная с версии 1.7, Pythran является зависимостью сборки (в настоящее время с возможностью отказа).

https://krex.k-state.edu/dspace/bitstream/handle/2097/7844/LD2668R41972S43.pdf#

Для различные причины, SciPy не может распространяться со встроенной поддержкой OpenMP. При использовании опциональной поддержки Pythran, параллельный код с поддержкой OpenMP может быть сгенерирован при сборке из исходников.

Другие библиотеки#

Может использоваться любая библиотека, соответствующая интерфейсу BLAS/LAPACK. Известно, что работают OpenBLAS, ATLAS, MKL, BLIS и эталонные библиотеки Netlib.

Библиотека	Минимальная версия
LAPACK	3.7.1
BLAS	Последняя версия OpenBLAS, MKL или ATLAS. Библиотека Accelerate BLAS больше не поддерживается.

Есть некоторые дополнительные опциональные зависимости.

Библиотека	Версия	URL
mpmath	Недавние	http://mpmath.org/
scikit-umfpack	Недавние	https://pypi.org/project/scikit-umfpack/
pooch	Недавние	https://pypi.org/project/pooch/

Более того, SciPy поддерживает взаимодействие с другими библиотеками. Набор тестов имеет дополнительные тесты совместимости, которые запускаются при их установке:

Инструмент	Версия	URL
pydata/sparse	Недавние	pydata/sparse

Тестирование и бенчмаркинг#

Тестирование и бенчмаркинг требуют последних версий:

Инструмент	Версия	URL
pytest	Недавние	https://docs.pytest.org/en/latest/
Гипотеза	Недавние	https://hypothesis.readthedocs.io/
asv (airspeed velocity)	Недавние	https://asv.readthedocs.io/

Сборка документации#

Инструмент	Версия
Sphinx	Любые последние версии работают. >= 5.0.
Тема PyData Sphinx	Любые последние версии работают. >= 0.15.2.
Sphinx-Design	Любые последние версии работают. >= 0.4.0.
numpydoc	Любые последние версии, которые работают. >= 1.5.0.
matplotlib	Обычно рекомендуется >= 3.5.
MyST-NB	Любые последние версии работают. >= 0.17.1
jupyterlite-sphinx	Любые последние версии работают. >= 0.17.1
jupyterlite-pyodide-kernel	Любые последние версии работают. >= 0.1.0

Примечание

Примечание для разработчиков: Версии numpy и matplotlib требования имеют последствия для примеров в строках документации Python. Примеры должны быть выполнимы как в среде, используемой для сборки документации, так и с любой поддерживаемой версией numpy/matplotlib которую пользователь может использовать с этой версией SciPy.

Упаковка#

Последняя версия:

Инструмент	Версия	URL
setuptools	Недавние	https://pypi.org/project/setuptools/
колесо	Недавние	https://pythonwheels.com
multibuild	Недавние	matthew-brett/multibuild