Upstream update available: python3-maturin 1.8.3 → 1.13.1 #1

Open
opened 2026-04-28 01:55:06 +03:00 by sbelikov · 0 comments
Owner

Upstream update available: python3-maturin 1.8.31.13.1

Package

  • Package: python3-maturin
  • RPM name: python3-maturin
  • Branch: niceos-5.2
  • Current EVR: 1.8.3-1
  • Update class: minor
  • Compare method: python_rpm
  • Update policy: leaf
  • Risk tags: standard

Upstream

Signals

  • Security-relevant keywords detected: False
  • Policy blocked: False
  • Policy reason: -
  • Labels: ai-summary, bot, needs-build, needs-triage, priority/medium, update/minor, upstream-update, upstream/pypi

NiceSOFT AI preliminary analysis

1. Краткий вывод

Предлагается обновление пакета python3-maturin с версии 1.8.3 до 1.13.1. Согласно метаданным, это классифицируется как минорное обновление (minor update), однако разница в номерах версий (1.8.x → 1.13.x) указывает на наличие множества промежуточных изменений, которые не описаны в предоставленных релиз-нотах. Автоматическое обновление отклонено из-за отсутствия детальной информации о содержании изменений между версиями.

2. Риск для НАЙС.ОС

medium.
Хотя обновление помечено как "minor" и имеет тег "standard", скачок с 1.8 до 1.13 версии подразумевает значительное количество накопленных изменений. Для инструмента сборки Rust-библиотек (maturin) такие изменения могут затрагивать логику компиляции, поддержку версий Python или зависимости от Rust toolchain, что требует проверки перед внедрением.

3. Security/CVE

Во входных данных отсутствуют признаки уязвимостей безопасности. Поле security_keywords_detected_by_script равно False, а поле policy_blocked равно False. В тексте релиз-нот не указаны исправления конкретных CVE или критических уязвимостей.

4. ABI/API риск

Данных недостаточно для оценки риска изменений ABI/API.
Поскольку релиз-ноты содержат только общее описание функциональности пакета, а не список изменений (changelog) между версиями 1.8.3 и 1.13.1, невозможно определить, были ли добавлены новые обязательные зависимости, изменены сигнатуры функций или изменен формат внутренних данных. Требуется ручной анализ diff исходного кода или официального changelog проекта.

5. Риск для RPM-сборки

Возможен риск нарушения сборки из-за изменений в зависимостях (BuildRequires) или требованиях к инструментам сборки (например, версия Rust compiler или Python). Поскольку update_policy установлен в leaf, а пакет является инструментом разработки, любые изменения в его внутренней логике могут повлиять на пакеты, использующие его для сборки. Также существует риск, что новые версии требуют более свежих системных библиотек, не входящих в текущий стек дистрибутива.

6. Проверки мейнтейнера

  • Найти и изучить официальный CHANGELOG.md или NEWS файл проекта maturin за период между версиями 1.8.3 и 1.13.1.
  • Проверить список зависимостей (requirements.txt или pyproject.toml upstream) на предмет появления новых обязательных пакетов или повышения требований к версиям существующих.
  • Убедиться, что новая версия совместима с поддерживаемыми версиями Python в НАЙС.ОС (особенно если поддержка старых версий Python была удалена).
  • Проверить, не изменился ли механизм работы с pyo3, cffi или uniffi, который может повлиять на пакеты, использующие python3-maturin для сборки.
  • Провести тестовую сборку пакета в изолированной среде с новой версией.

7. Рекомендация

blocked manual review

8. Основание рекомендации

Обновление заблокировано для автоматической обработки из-за большого разрыва в номерах версий (1.8 → 1.13) при отсутствии детального списка изменений в предоставленных данных. Это классифицируется как потенциально рискованное обновление для инструмента сборки, где скрытые изменения в зависимостях или логике могут сломать процесс сборки зависимых пакетов. Требуется ручная проверка changelog и тестирование.

Upstream release notes / description

Build and publish crates with pyo3, cffi and uniffi bindings as well as rust binaries as python packages

Maturin

formerly pyo3-pack

Maturin User Guide
Crates.io
PyPI
discord server

Build and publish crates with pyo3, cffi and uniffi bindings as well as rust binaries as python packages with minimal configuration.
It supports building wheels for python 3.8+ on Windows, Linux, macOS and FreeBSD, can upload them to pypi and has basic PyPy and GraalPy support.

Check out the User Guide!

Usage

You can either download binaries from the latest release or install it with pipx or uv:

# pipx
pipx install maturin
# uv
uv tool install maturin

Note

pip install maturin should also work if you don't want to use pipx.

There are three main commands:

  • maturin new creates a new cargo project with maturin configured.
  • maturin build builds the wheels and stores them in a folder (target/wheels by default), but doesn't upload them. It's recommended to publish packages with uv using uv publish.
  • maturin develop builds the crate and installs it as a python module directly in the current virtualenv. Note that while maturin develop is faster, it doesn't support all the feature that running pip install after maturin build supports.

maturin doesn't need extra configuration files and doesn't clash with an existing setuptools-rust configuration.
You can even integrate it with testing tools such as tox.
There are examples for the different bindings in the test-crates folder.

The name of the package will be the name of the cargo project, i.e. the name field in the [package] section of Cargo.toml.
The name of the module, which you are using when importing, will be the name value in the [lib] section (which defaults to the name of the package). For binaries, it's simply the name of the binary generated by cargo.

When using maturin build and maturin develop commands, you can compile a performance-optimized program by adding the -r or --release flag.

Python packaging basics

Python packages come in two formats:
A built form called wheel and source distributions (sdist), both of which are archives.
A wheel can be compatible with any python version, interpreter (cpython and pypy, mainly), operating system and hardware architecture (for pure python wheels),
can be limited to a specific platform and architecture (e.g. when using ctypes or cffi) or to a specific python interpreter and version on a specific architecture and operating system (e.g. with pyo3).

When using pip install on a package, pip tries to find a matching wheel and install that. If it doesn't find one, it downloads the source distribution and builds a wheel for the current platform,
which requires the right compilers to be installed. Installing a wheel is much faster than installing a source distribution as building wheels is generally slow.

When you publish a package to be installable with pip install, you upload it to pypi, the official package repository.
For testing, you can use test pypi instead, which you can use with pip install --index-url https://test.pypi.org/simple/.
Note that for publishing for linux, you need to use the manylinux docker container or zig, while for publishing from your repository you can use the [PyO3

NiceOS maintainer checklist

  • Confirm that the detected version is a stable upstream release.
  • Check upstream changelog for security fixes, ABI/API changes and build-system changes.
  • Check ABI/API compatibility and reverse dependencies.
  • Download source into NiceOS lookaside storage.
  • Update Version and related fields in SPECS/*.spec only if policy allows it.
  • Regenerate SOURCES/sources.lock.json, manifests, metadata and SBOM.
  • Build SRPM/RPM in a clean NiceOS buildroot.
  • Run package smoke tests.
  • Link PR/build logs and close this issue after update or triage.

Bot metadata

  • Tool: niceos_upstream_monitor.py 1.4
  • Generated at: 2026-04-27T22:55:05Z
<!-- niceos-upstream-monitor:fingerprint=upstream-update:python3-maturin:1.13.1 --> <!-- niceos-upstream-monitor:package=python3-maturin --> <!-- niceos-upstream-monitor:current=1.8.3 --> <!-- niceos-upstream-monitor:latest=1.13.1 --> # Upstream update available: `python3-maturin` `1.8.3` → `1.13.1` ## Package - Package: `python3-maturin` - RPM name: `python3-maturin` - Branch: `niceos-5.2` - Current EVR: `1.8.3-1` - Update class: `minor` - Compare method: `python_rpm` - Update policy: `leaf` - Risk tags: `standard` ## Upstream - Upstream type: `pypi` - Upstream project: `-` - Upstream URL: https://files.pythonhosted.org/packages/30/0b/3fd746cf5cfa3c8d7e20ea08c0dbc2c2c765ae051d0fc43d808a38bc9548/maturin-1.8.3.tar.gz - Detected version: `1.13.1` - Tag/release: `1.13.1` - Source: `pypi_json` - Published: `2026-04-09T15:14:07.026326Z` - Release URL: https://pypi.org/project/maturin/ - Source URL: https://files.pythonhosted.org/packages/39/16/b284a7bc4af3dd87717c784278c1b8cb18606ad1f6f7a671c47bfd9c3df0/maturin-1.13.1.tar.gz - Pre-release: `False` ## Signals - Security-relevant keywords detected: `False` - Policy blocked: `False` - Policy reason: `-` - Labels: `ai-summary, bot, needs-build, needs-triage, priority/medium, update/minor, upstream-update, upstream/pypi` ## NiceSOFT AI preliminary analysis ### 1. Краткий вывод Предлагается обновление пакета `python3-maturin` с версии 1.8.3 до 1.13.1. Согласно метаданным, это классифицируется как минорное обновление (minor update), однако разница в номерах версий (1.8.x → 1.13.x) указывает на наличие множества промежуточных изменений, которые не описаны в предоставленных релиз-нотах. Автоматическое обновление отклонено из-за отсутствия детальной информации о содержании изменений между версиями. ### 2. Риск для НАЙС.ОС **medium**. Хотя обновление помечено как "minor" и имеет тег "standard", скачок с 1.8 до 1.13 версии подразумевает значительное количество накопленных изменений. Для инструмента сборки Rust-библиотек (maturin) такие изменения могут затрагивать логику компиляции, поддержку версий Python или зависимости от Rust toolchain, что требует проверки перед внедрением. ### 3. Security/CVE Во входных данных отсутствуют признаки уязвимостей безопасности. Поле `security_keywords_detected_by_script` равно `False`, а поле `policy_blocked` равно `False`. В тексте релиз-нот не указаны исправления конкретных CVE или критических уязвимостей. ### 4. ABI/API риск Данных недостаточно для оценки риска изменений ABI/API. Поскольку релиз-ноты содержат только общее описание функциональности пакета, а не список изменений (changelog) между версиями 1.8.3 и 1.13.1, невозможно определить, были ли добавлены новые обязательные зависимости, изменены сигнатуры функций или изменен формат внутренних данных. Требуется ручной анализ diff исходного кода или официального changelog проекта. ### 5. Риск для RPM-сборки Возможен риск нарушения сборки из-за изменений в зависимостях (`BuildRequires`) или требованиях к инструментам сборки (например, версия Rust compiler или Python). Поскольку `update_policy` установлен в `leaf`, а пакет является инструментом разработки, любые изменения в его внутренней логике могут повлиять на пакеты, использующие его для сборки. Также существует риск, что новые версии требуют более свежих системных библиотек, не входящих в текущий стек дистрибутива. ### 6. Проверки мейнтейнера - Найти и изучить официальный `CHANGELOG.md` или `NEWS` файл проекта `maturin` за период между версиями 1.8.3 и 1.13.1. - Проверить список зависимостей (`requirements.txt` или `pyproject.toml` upstream) на предмет появления новых обязательных пакетов или повышения требований к версиям существующих. - Убедиться, что новая версия совместима с поддерживаемыми версиями Python в НАЙС.ОС (особенно если поддержка старых версий Python была удалена). - Проверить, не изменился ли механизм работы с `pyo3`, `cffi` или `uniffi`, который может повлиять на пакеты, использующие `python3-maturin` для сборки. - Провести тестовую сборку пакета в изолированной среде с новой версией. ### 7. Рекомендация blocked manual review ### 8. Основание рекомендации Обновление заблокировано для автоматической обработки из-за большого разрыва в номерах версий (1.8 → 1.13) при отсутствии детального списка изменений в предоставленных данных. Это классифицируется как потенциально рискованное обновление для инструмента сборки, где скрытые изменения в зависимостях или логике могут сломать процесс сборки зависимых пакетов. Требуется ручная проверка changelog и тестирование. ## Upstream release notes / description Build and publish crates with pyo3, cffi and uniffi bindings as well as rust binaries as python packages # Maturin _formerly pyo3-pack_ [![Maturin User Guide](https://img.shields.io/badge/user-guide-brightgreen?logo=readthedocs&style=flat-square)](https://maturin.rs) [![Crates.io](https://img.shields.io/crates/v/maturin.svg?logo=rust&style=flat-square)](https://crates.io/crates/maturin) [![PyPI](https://img.shields.io/pypi/v/maturin.svg?logo=python&style=flat-square)](https://pypi.org/project/maturin) [![discord server](https://img.shields.io/discord/1209263839632424990?logo=discord&style=flat-square)](https://discord.gg/33kcChzH7f) Build and publish crates with [pyo3, cffi and uniffi bindings](https://maturin.rs/bindings) as well as rust binaries as python packages with minimal configuration. It supports building wheels for python 3.8+ on Windows, Linux, macOS and FreeBSD, can upload them to [pypi](https://pypi.org/) and has basic PyPy and GraalPy support. Check out the [User Guide](https://maturin.rs/)! ## Usage You can either download binaries from the [latest release](https://github.com/PyO3/maturin/releases/latest) or install it with [pipx](https://pypa.github.io/pipx/) or [uv](https://github.com/astral-sh/uv): ```shell # pipx pipx install maturin # uv uv tool install maturin ``` > [!NOTE] > > `pip install maturin` should also work if you don't want to use pipx. There are three main commands: - `maturin new` creates a new cargo project with maturin configured. - `maturin build` builds the wheels and stores them in a folder (`target/wheels` by default), but doesn't upload them. It's recommended to publish packages with [uv](https://github.com/astral-sh/uv) using `uv publish`. - `maturin develop` builds the crate and installs it as a python module directly in the current virtualenv. Note that while `maturin develop` is faster, it doesn't support all the feature that running `pip install` after `maturin build` supports. maturin doesn't need extra configuration files and doesn't clash with an existing setuptools-rust configuration. You can even integrate it with testing tools such as [tox](https://tox.readthedocs.io/en/latest/). There are examples for the different bindings in the `test-crates` folder. The name of the package will be the name of the cargo project, i.e. the name field in the `[package]` section of `Cargo.toml`. The name of the module, which you are using when importing, will be the `name` value in the `[lib]` section (which defaults to the name of the package). For binaries, it's simply the name of the binary generated by cargo. When using `maturin build` and `maturin develop` commands, you can compile a performance-optimized program by adding the `-r` or `--release` flag. ## Python packaging basics Python packages come in two formats: A built form called wheel and source distributions (sdist), both of which are archives. A wheel can be compatible with any python version, interpreter (cpython and pypy, mainly), operating system and hardware architecture (for pure python wheels), can be limited to a specific platform and architecture (e.g. when using ctypes or cffi) or to a specific python interpreter and version on a specific architecture and operating system (e.g. with pyo3). When using `pip install` on a package, pip tries to find a matching wheel and install that. If it doesn't find one, it downloads the source distribution and builds a wheel for the current platform, which requires the right compilers to be installed. Installing a wheel is much faster than installing a source distribution as building wheels is generally slow. When you publish a package to be installable with `pip install`, you upload it to [pypi](https://pypi.org/), the official package repository. For testing, you can use [test pypi](https://test.pypi.org/) instead, which you can use with `pip install --index-url https://test.pypi.org/simple/`. Note that for [publishing for linux](#manylinux-and-auditwheel), you need to use the manylinux docker container or zig, while for publishing from your repository you can use the [PyO3 ## NiceOS maintainer checklist - [ ] Confirm that the detected version is a stable upstream release. - [ ] Check upstream changelog for security fixes, ABI/API changes and build-system changes. - [ ] Check ABI/API compatibility and reverse dependencies. - [ ] Download source into NiceOS lookaside storage. - [ ] Update `Version` and related fields in `SPECS/*.spec` only if policy allows it. - [ ] Regenerate `SOURCES/sources.lock.json`, manifests, metadata and SBOM. - [ ] Build SRPM/RPM in a clean NiceOS buildroot. - [ ] Run package smoke tests. - [ ] Link PR/build logs and close this issue after update or triage. ## Bot metadata - Tool: `niceos_upstream_monitor.py 1.4` - Generated at: `2026-04-27T22:55:05Z`
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
rpms/python3-maturin#1
No description provided.