rpms/python3-pathspec
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

Upstream update available: python3-pathspec 0.12.1 → 1.1.1 #1

New issue
Open
opened 2026-04-28 01:57:27 +03:00 by sbelikov · 0 comments
sbelikov commented 2026-04-28 01:57:27 +03:00
Owner
Copy link

Upstream update available: python3-pathspec 0.12.1 → 1.1.1

Package

  • Package: python3-pathspec
  • RPM name: python3-pathspec
  • Branch: niceos-5.2
  • Current EVR: 0.12.1-1
  • Update class: major
  • 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/high, update/major, upstream-update, upstream/pypi

NiceSOFT AI preliminary analysis

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

Обнаружено обновление библиотеки python3-pathspec с версии 0.12.1 до 1.1.1, которое классифицируется как мажорное (major). Обновление затрагивает API и поведение библиотеки, что требует тщательной проверки совместимости с существующими приложениями дистрибутива. Автоматическое применение обновления не рекомендуется без предварительного анализа зависимостей.

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

medium.
Обновление является мажорным (update_class: major), что подразумевает вероятные изменения в публичном API или внутреннем поведении библиотеки. Поскольку пакет помечен как leaf (не является критической базовой зависимостью вроде glibc или kernel), прямой риск для стабильности системы ниже, чем у toolchain, но риск поломки приложений, использующих эту библиотеку, остается значительным из-за смены мажорной версии.

3. Security/CVE

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

4. ABI/API риск

Высокий риск изменений API. Переход с версии 0.x на 1.x часто сопровождается изменением сигнатур функций, удалением устаревших методов или изменением поведения по умолчанию. Для точной оценки необходимо сравнить исходный код версий 0.12.1 и 1.1.1, а также проверить все места использования этого пакета в коде дистрибутива. Без ручного анализа утверждать о конкретных изменениях невозможно.

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

Поскольку это библиотека Python, основные риски связаны с:

  • Изменением требований к зависимостям (BuildRequires), если новая версия требует другие версии системных библиотек (например, hyperscan или re2, упомянутые в релиз-нотах как опциональные бэкенды).
  • Сбоем тестов %check, если они зависят от конкретного поведения API, изменившегося при мажорном обновлении.
  • Проблемами с setuptools или механизмом сборки, если структура проекта в tarball изменилась существенно.

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

  • Проверить наличие пакетов, зависящих от python3-pathspec в репозитории НАЙС.ОС.
  • Сравнить публичный API версий 0.12.1 и 1.1.1 (документация или исходный код).
  • Убедиться, что в релиз-нотах нет скрытых зависимостей от внешних C-библиотек (hyperscan/re2), которые могут отсутствовать в текущей сборке.
  • Провести локальную сборку пакета с новой версией и запуск тестов.
  • Проверить логи приложений дистрибутива на предмет ошибок, связанных с pathspec.

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

issue-only

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

Обновление классифицировано как мажорное (major), что автоматически блокирует автоматическое применение. Отсутствие данных о CVE и явных указаний на безопасность не позволяет рекомендовать обновление как кандидата. Необходим ручной анализ изменений API и проверка зависимостей перед любым обновлением.

Upstream release notes / description

Utility library for gitignore style pattern matching of file paths.

PathSpec

pathspec is a utility library for pattern matching of file paths. So far this
only includes Git's gitignore_ pattern matching.

.. _gitignore: http://git-scm.com/docs/gitignore

Tutorial

Say you have a "Projects" directory and you want to back it up, but only
certain files, and ignore others depending on certain conditions::

>>> from pathspec import PathSpec
>>> # The gitignore-style patterns for files to select, but we're including
>>> # instead of ignoring.
>>> spec_text = """
...
... # This is a comment because the line begins with a hash: "#"
...
... # Include several project directories (and all descendants) relative to
... # the current directory. To reference only a directory you must end with a
... # slash: "/"
... /project-a/
... /project-b/
... /project-c/
...
... # Patterns can be negated by prefixing with exclamation mark: "!"
...
... # Ignore temporary files beginning or ending with "~" and ending with
... # ".swp".
... !~*
... !*~
... !*.swp
...
... # These are python projects so ignore compiled python files from
... # testing.
... !*.pyc
...
... # Ignore the build directories but only directly under the project
... # directories.
... !/*/build/
...
... """

The PathSpec class provides an abstraction around pattern implementations,
and we want to compile our patterns as "gitignore" patterns. You could call it a
wrapper for a list of compiled patterns::

>>> spec = PathSpec.from_lines('gitignore', spec_text.splitlines())

If we wanted to manually compile the patterns, we can use the GitIgnoreBasicPattern
class directly. It is used in the background for "gitignore" which internally
converts patterns to regular expressions::

>>> from pathspec.patterns.gitignore.basic import GitIgnoreBasicPattern
>>> patterns = map(GitIgnoreBasicPattern, spec_text.splitlines())
>>> spec = PathSpec(patterns)

PathSpec.from_lines() is a class method which simplifies that.

If you want to load the patterns from file, you can pass the file object
directly as well::

>>> with open('patterns.list', 'r') as fh:
>>>     spec = PathSpec.from_lines('gitignore', fh)

You can perform matching on a whole directory tree with::

>>> matches = set(spec.match_tree_files('path/to/directory'))

Or you can perform matching on a specific set of file paths with::

>>> matches = set(spec.match_files(file_paths))

Or check to see if an individual file matches::

>>> is_matched = spec.match_file(file_path)

There's actually two implementations of "gitignore". The basic implementation is
used by PathSpec and follows patterns as documented by gitignore_.
However, Git's behavior differs from the documented patterns. There's some
edge-cases, and in particular, Git allows including files from excluded
directories which appears to contradict the documentation. GitIgnoreSpec
handles these cases to more closely replicate Git's behavior::

>>> from pathspec import GitIgnoreSpec
>>> spec = GitIgnoreSpec.from_lines(spec_text.splitlines())

You do not specify the style of pattern for GitIgnoreSpec because it should
always use GitIgnoreSpecPattern internally.

Performance

Running lots of regular expression matches against thousands of files in Python
is slow. Alternate regular expression backends can be used to improve
performance. PathSpec and GitIgnoreSpec both accept a backend
parameter to control the backend. The default is "best" to automatically choose
the best available backend. There are currently 3 backends.

The "simple" backend is the default and it simply uses Python's re.Pattern
objects that are normally created. This can be the fastest when there's only 1
or 2 patterns.

The "hyperscan" backend uses the hyperscan_ library. Hyperscan tends to be at
least 2 times faster than "simple", and generally slower than "re2". This can be
faster than "re2" under the right conditions with pattern counts of 1-25.

The "re2" backen

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:57:27Z
<!-- niceos-upstream-monitor:fingerprint=upstream-update:python3-pathspec:1.1.1 --> <!-- niceos-upstream-monitor:package=python3-pathspec --> <!-- niceos-upstream-monitor:current=0.12.1 --> <!-- niceos-upstream-monitor:latest=1.1.1 --> # Upstream update available: `python3-pathspec` `0.12.1` → `1.1.1` ## Package - Package: `python3-pathspec` - RPM name: `python3-pathspec` - Branch: `niceos-5.2` - Current EVR: `0.12.1-1` - Update class: `major` - Compare method: `python_rpm` - Update policy: `leaf` - Risk tags: `standard` ## Upstream - Upstream type: `pypi` - Upstream project: `-` - Upstream URL: https://files.pythonhosted.org/packages/source/p/pathspec/pathspec-0.12.1.tar.gz - Detected version: `1.1.1` - Tag/release: `1.1.1` - Source: `pypi_json` - Published: `2026-04-27T01:46:08.907631Z` - Release URL: https://pypi.org/project/pathspec/ - Source URL: https://files.pythonhosted.org/packages/5a/82/42f767fc1c1143d6fd36efb827202a2d997a375e160a71eb2888a925aac1/pathspec-1.1.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/high, update/major, upstream-update, upstream/pypi` ## NiceSOFT AI preliminary analysis ### 1. Краткий вывод Обнаружено обновление библиотеки `python3-pathspec` с версии 0.12.1 до 1.1.1, которое классифицируется как мажорное (major). Обновление затрагивает API и поведение библиотеки, что требует тщательной проверки совместимости с существующими приложениями дистрибутива. Автоматическое применение обновления не рекомендуется без предварительного анализа зависимостей. ### 2. Риск для НАЙС.ОС **medium**. Обновление является мажорным (`update_class: major`), что подразумевает вероятные изменения в публичном API или внутреннем поведении библиотеки. Поскольку пакет помечен как `leaf` (не является критической базовой зависимостью вроде glibc или kernel), прямой риск для стабильности системы ниже, чем у toolchain, но риск поломки приложений, использующих эту библиотеку, остается значительным из-за смены мажорной версии. ### 3. Security/CVE Во входных данных отсутствуют признаки уязвимостей безопасности. Поле `security_keywords_detected_by_script` равно `False`, а список CVE не предоставлен. Текст релиз-нотов описывает функциональные улучшения и документацию, но не упоминает исправления уязвимостей. ### 4. ABI/API риск Высокий риск изменений API. Переход с версии 0.x на 1.x часто сопровождается изменением сигнатур функций, удалением устаревших методов или изменением поведения по умолчанию. Для точной оценки необходимо сравнить исходный код версий 0.12.1 и 1.1.1, а также проверить все места использования этого пакета в коде дистрибутива. Без ручного анализа утверждать о конкретных изменениях невозможно. ### 5. Риск для RPM-сборки Поскольку это библиотека Python, основные риски связаны с: - Изменением требований к зависимостям (`BuildRequires`), если новая версия требует другие версии системных библиотек (например, `hyperscan` или `re2`, упомянутые в релиз-нотах как опциональные бэкенды). - Сбоем тестов `%check`, если они зависят от конкретного поведения API, изменившегося при мажорном обновлении. - Проблемами с `setuptools` или механизмом сборки, если структура проекта в tarball изменилась существенно. ### 6. Проверки мейнтейнера - [ ] Проверить наличие пакетов, зависящих от `python3-pathspec` в репозитории НАЙС.ОС. - [ ] Сравнить публичный API версий 0.12.1 и 1.1.1 (документация или исходный код). - [ ] Убедиться, что в релиз-нотах нет скрытых зависимостей от внешних C-библиотек (hyperscan/re2), которые могут отсутствовать в текущей сборке. - [ ] Провести локальную сборку пакета с новой версией и запуск тестов. - [ ] Проверить логи приложений дистрибутива на предмет ошибок, связанных с `pathspec`. ### 7. Рекомендация issue-only ### 8. Основание рекомендации Обновление классифицировано как мажорное (`major`), что автоматически блокирует автоматическое применение. Отсутствие данных о CVE и явных указаний на безопасность не позволяет рекомендовать обновление как кандидата. Необходим ручной анализ изменений API и проверка зависимостей перед любым обновлением. ## Upstream release notes / description Utility library for gitignore style pattern matching of file paths. PathSpec ======== *pathspec* is a utility library for pattern matching of file paths. So far this only includes Git's `gitignore`_ pattern matching. .. _`gitignore`: http://git-scm.com/docs/gitignore Tutorial -------- Say you have a "Projects" directory and you want to back it up, but only certain files, and ignore others depending on certain conditions:: >>> from pathspec import PathSpec >>> # The gitignore-style patterns for files to select, but we're including >>> # instead of ignoring. >>> spec_text = """ ... ... # This is a comment because the line begins with a hash: "#" ... ... # Include several project directories (and all descendants) relative to ... # the current directory. To reference only a directory you must end with a ... # slash: "/" ... /project-a/ ... /project-b/ ... /project-c/ ... ... # Patterns can be negated by prefixing with exclamation mark: "!" ... ... # Ignore temporary files beginning or ending with "~" and ending with ... # ".swp". ... !~* ... !*~ ... !*.swp ... ... # These are python projects so ignore compiled python files from ... # testing. ... !*.pyc ... ... # Ignore the build directories but only directly under the project ... # directories. ... !/*/build/ ... ... """ The ``PathSpec`` class provides an abstraction around pattern implementations, and we want to compile our patterns as "gitignore" patterns. You could call it a wrapper for a list of compiled patterns:: >>> spec = PathSpec.from_lines('gitignore', spec_text.splitlines()) If we wanted to manually compile the patterns, we can use the ``GitIgnoreBasicPattern`` class directly. It is used in the background for "gitignore" which internally converts patterns to regular expressions:: >>> from pathspec.patterns.gitignore.basic import GitIgnoreBasicPattern >>> patterns = map(GitIgnoreBasicPattern, spec_text.splitlines()) >>> spec = PathSpec(patterns) ``PathSpec.from_lines()`` is a class method which simplifies that. If you want to load the patterns from file, you can pass the file object directly as well:: >>> with open('patterns.list', 'r') as fh: >>> spec = PathSpec.from_lines('gitignore', fh) You can perform matching on a whole directory tree with:: >>> matches = set(spec.match_tree_files('path/to/directory')) Or you can perform matching on a specific set of file paths with:: >>> matches = set(spec.match_files(file_paths)) Or check to see if an individual file matches:: >>> is_matched = spec.match_file(file_path) There's actually two implementations of "gitignore". The basic implementation is used by ``PathSpec`` and follows patterns as documented by `gitignore`_. However, Git's behavior differs from the documented patterns. There's some edge-cases, and in particular, Git allows including files from excluded directories which appears to contradict the documentation. ``GitIgnoreSpec`` handles these cases to more closely replicate Git's behavior:: >>> from pathspec import GitIgnoreSpec >>> spec = GitIgnoreSpec.from_lines(spec_text.splitlines()) You do not specify the style of pattern for ``GitIgnoreSpec`` because it should always use ``GitIgnoreSpecPattern`` internally. Performance ----------- Running lots of regular expression matches against thousands of files in Python is slow. Alternate regular expression backends can be used to improve performance. ``PathSpec`` and ``GitIgnoreSpec`` both accept a ``backend`` parameter to control the backend. The default is "best" to automatically choose the best available backend. There are currently 3 backends. The "simple" backend is the default and it simply uses Python's ``re.Pattern`` objects that are normally created. This can be the fastest when there's only 1 or 2 patterns. The "hyperscan" backend uses the `hyperscan`_ library. Hyperscan tends to be at least 2 times faster than "simple", and generally slower than "re2". This can be faster than "re2" under the right conditions with pattern counts of 1-25. The "re2" backen ## 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:57:27Z`
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
niceos-5.2
No results found.
Labels
Clear labels   
ai-summary
Issue contains local NiceSOFT AI generated preliminary analysis

  
bot
Created by automation

  
needs-build
Needs build verification

  
needs-triage
Needs maintainer triage

  
priority/high
High priority

  
update/major
Major update

  
upstream-update
New upstream version is available

  
upstream/pypi
PyPI upstream

No labels
ai-summary
bot
needs-build
needs-triage
priority/high
update/major
upstream-update
upstream/pypi
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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-pathspec#1
No description provided.