Package Details: python-blake3 0.3.3-2

Git Clone URL: https://aur.archlinux.org/python-blake3.git (read-only, click to copy)
Package Base: python-blake3
Description: Python bindings for the BLAKE3 cryptographic hash function
Upstream URL: https://github.com/oconnor663/blake3-py
Keywords: blake3 hash python
Licenses: Apache, Custom:CC0-1.0
Submitter: gmes78
Maintainer: gmes78 (oconnor663)
Last Packager: oconnor663
Votes: 2
Popularity: 0.000000
First Submitted: 2020-02-29 18:31 (UTC)
Last Updated: 2023-06-07 06:04 (UTC)

Latest Comments

oconnor663 commented on 2023-06-07 06:11 (UTC)

Thanks! Pushed.

gmes78 commented on 2023-06-07 04:01 (UTC)

@oconnor663 Sure thing.

(I didn't see your previous message, sorry about that. You can go ahead and make that change.)

oconnor663 commented on 2023-06-07 03:57 (UTC)

I'd be happy to be a co-maintainer of this package if you like. I'd like to bump the pkgrel to celebrate Python 3.11, and I can also add the virtualenv check below.

oconnor663 commented on 2022-12-28 17:03 (UTC)

@kseistrup interesting! I picked the Python AUR package with the most votes (python-pynput) and tried installing that in a venv, and that runs into a vaguely similar issue. In that case the package fails to build, though, which is probably better than passing the build and installing nonsense. Maybe we could insert an extra check something like this?

if [[ -n "$VIRTUAL_ENV" ]]; then
    echo 'ERROR: $VIRTUAL_ENV is set, which means the build is running in a virtual Python environment.'
    echo 'ERROR: Rerun the build in a fresh terminal, using the default/system Python environment.'
    exit 1
fi

kseistrup commented on 2022-12-28 15:31 (UTC)

Please note that if you have a user pyenv configuration for e.g. Python 3.11 and if that user uses yay -S python-blake3 with the intention of installing the package system-wide, it will fail: Most of the package contents will land in ~/.pyenv/versions/3.11.0/lib/python3.11/site-packages/, only the license will land in the correct place.

oconnor663 commented on 2020-03-07 01:15 (UTC)

Today I learned! Thanks for the quick turnaround.

gmes78 commented on 2020-03-07 01:13 (UTC)

@oconnor663 I've changed the makedepend to rustup for now.

I didn't add a makedepend for a C compiler, as gcc belongs to the base-devel group, and, according to the wiki, the base-devel group can be assumed to be installed and its packages should not be included in the makedepends.

oconnor663 commented on 2020-03-06 23:19 (UTC) (edited on 2020-03-06 23:19 (UTC) by oconnor663)

The rust-toolchain file at the root of the project currently pins a specific nightly compiler version. Rustup will then download and invoke that specific version. The build will probably fail if you have a non-rustup Rust installation, and we might want to explicitly depend on rustup for that reason. (A tracking issue for this unfortunate behavior: https://github.com/oconnor663/blake3-py/issues/3.)

The Cargo.toml file explicitly enables the "c" feature of the underlying blake3 Rust crate, to link in assembly implementations and AVX-512 support. This requires a C compiler, which we might also want to specify in the makedepends.