Package Details: python-cyclonedx-lib 8.5.0-1

Git Clone URL: https://aur.archlinux.org/python-cyclonedx-lib.git (read-only, click to copy)
Package Base: python-cyclonedx-lib
Description: Render and read CycloneDX, a lightweight BOM specification document format
Upstream URL: https://github.com/CycloneDX/cyclonedx-python-lib
Licenses: Apache-2.0
Conflicts: python-cyclonedx-lib-git
Submitter: Auerhuhn
Maintainer: Auerhuhn
Last Packager: Auerhuhn
Votes: 0
Popularity: 0.000000
First Submitted: 2021-11-11 12:12 (UTC)
Last Updated: 2024-12-22 20:33 (UTC)

Latest Comments

1 2 Next › Last »

gesh commented on 2025-02-26 15:56 (UTC)

And cyclonedx-python-lib 9.0.2 just landed, with the compatibility for python-py-serializable 2.0.0 added. Both can be upgraded now.

gesh commented on 2025-02-09 15:12 (UTC)

Heads' up -- python-py-serializable 2.0.0 just released, with backwards-incompatible renaming of modules. (Thankfully, you (@Auerhuhn) package both, so you don't need to deal with a packager bumping the version from under you, but still thought I'd flag this)

On the cyclonedx end, the patch blocking bumping the packaged py-serializable version is https://github.com/CycloneDX/cyclonedx-python-lib/pull/775

Auerhuhn commented on 2024-12-23 19:23 (UTC)

@gesh All right. In case this ever occurs again, feel free to drop me the details.

gesh commented on 2024-12-23 19:03 (UTC)

Unfortunately, I've already closed the terminal window where I ran into the bug. If I recall correctly, the complaint was that /usr/lib/python3.13/site-packages/cyclonedx already existed. I'm sorry I didn't keep that log around before posting the comment.

Auerhuhn commented on 2024-12-23 17:27 (UTC)

@gesh With that being said: the check() absolutely should not fail, not even with Python v3.13 in place. If you can still reproduce the failure, mind providing me a stack trace, and/or try in a clean chroot?

Even if I’m going to remove the isolation on the next update no matter what, I’d still like to understand the problem first.

I generally aim for reasonably stable and deterministic PKGBUILDs, plus I use similar isolation techniques in several other PKGBUILDs. Understanding what’s going on would benefit those, too.

Auerhuhn commented on 2024-12-23 17:21 (UTC)

@gesh Thanks for the pointer. In 2022, I added the temporary PYTHONPATH in 69836c8f, back then in the form of a virtual environment but the rationale and effect were the same: without a dedicated installation/venv, the test_e2e_environment test (and a handful of similar tests) would bail with e.g.:

pkg_resources.DistributionNotFound: The 'cyclonedx-python-lib' distribution was not found and is required by the application

However, it turns out that all the offending tests were removed in 2023 via upstream commit 26b151c, so the isolation from the cwd hasn’t been necessary since upstream v5.x. So I think we can do away with the isolation.

gesh commented on 2024-12-23 16:37 (UTC)

Note that the temp install in check() breaks when moving from Python 3.12 to 3.13. Commenting it out allows the package to build, following which it can be restored. I am referring to

  local _site_packages
  _site_packages="$(python -c 'import site; print(site.getsitepackages()[0])')"
  python -m installer --destdir=tmp_install dist/*.whl
  PYTHONPATH="${PWD}/tmp_install/${_site_packages}" python -m unittest discover -v

I am uncertain what this temporary installation is supposed to achieve? Isn't a simple

python -m unittest discover -v

enough?

Auerhuhn commented on 2024-12-23 16:34 (UTC)

@gesh A pkgrel bump would be useless, because by the time I pushed 8.5.0-1, Python 3.13 had been published to core already.

gesh commented on 2024-12-23 14:40 (UTC) (edited on 2024-12-23 14:43 (UTC) by gesh)

Note: Package needs to be rebuilt for Python 3.13 (a bump to pkgrel suffices)

gesh commented on 2024-09-30 13:55 (UTC)

Note -- given that we're not building with the python-setuptools backend, the python-wheel makedep is unnecessary.

1 2 Next › Last »