Package Details: python-safetensors 0.4.3-2

Git Clone URL: https://aur.archlinux.org/python-safetensors.git (read-only, click to copy)
Package Base: python-safetensors
Description: Simple, safe way to store and distribute tensors
Upstream URL: https://github.com/huggingface/safetensors
Licenses: Apache
Submitter: Henry-ZHR
Maintainer: mane.andrea
Last Packager: mane.andrea
Votes: 3
Popularity: 1.64
First Submitted: 2023-01-08 09:54 (UTC)
Last Updated: 2024-04-17 17:56 (UTC)

Dependencies (27)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 Next › Last »

65a commented on 2023-11-18 02:52 (UTC) (edited on 2023-11-18 02:59 (UTC) by 65a)

@phoenix17, I'm glad it works for you, but it doesn't work for me. The result is still failing to import safetensors.torch or crashing in the check() (this depends on which machine I use?!), using a clean git clone of the AUR source then makepkg -si on multiple machines. Here is one failure log: https://pastebin.com/mppuQw0H

phoenix17 commented on 2023-11-16 20:07 (UTC)

In case this helps someone, I was able to build/install this manually via makepkg -si without making any changes to the build script here: https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=python-safetensors

I can confirm it also worked with python-transformers package on the aur and pytorch (https://archlinux.org/packages/extra/x86_64/python-pytorch/)

pulsarGuy commented on 2023-11-16 04:00 (UTC) (edited on 2023-11-16 04:03 (UTC) by pulsarGuy)

I wound up in @tomsod's situation, and their solution worked for me. Skipping checks did allow the package to be installed, but attempting to import it within python failed. Removing --wheel caused the checks to be successful, the package to be installed, and allowed importing within python. Unfortunately, I do not use torch, so I can't comment on that aspect.

65a commented on 2023-11-14 02:13 (UTC)

This package doesn't properly provide safetensors.torch import. If I follow @tomsod's advice, I can't even import safetensors. I suspect it's something between src and py-src directories, but I don't understand python packaging well enough to understand why this is isn't working (PKGBUILD changes look reasonable, but maybe something new is needed to support an upstream change? idk)

Tomsod commented on 2023-11-08 04:10 (UTC) (edited on 2023-11-08 04:10 (UTC) by Tomsod)

Tests failed for me too, so I skipped them, but the build package didn't work either. Turns out the --wheel option in build() somehow prevents these files from being installed. Without it, everything seems to work fine.

Henry-ZHR commented on 2023-08-01 05:06 (UTC)

@ruro

there doesn't seem to be a way to permanently disable check for a single package

AFAIK, you're right.

What I usually do:

  1. yay, skip these packages

  2. yay -Syu --mflags --nocheck

Maybe someone can issue a feature request to AUR helpers, but not me.

ruro commented on 2023-07-30 15:29 (UTC)

@Henry-ZHR

That's what you think, but not what arch devs think. See https://man.archlinux.org/man/PKGBUILD.5.

Huh. Damn, it seems that you are right. I must have been remembering it wrong.

Well, I suggest simply disabling the tests if you don't want those huge packages to be installed.

Please, correct me if I am wrong, but there doesn't seem to be a way to permanently disable check for a single package? So you either have to disable check globally for all packages in makepkg.conf or you have to do it manually each time the package is updated (which doesn't play well with AUR helpers).

Henry-ZHR commented on 2023-07-30 15:07 (UTC)

@ruro

The purpose of the check step is to verify some basic assertions about the built software.

That's what you think, but not what arch devs think. See https://man.archlinux.org/man/PKGBUILD.5.

An optional check() function can be specified in which a package’s test-suite may be run.

validating compatibility with ALL opt-depends is overkill in this case

You are right, but I don't have better solution. Maybe we can select/deselect tests according to whether we have the dependency installed? But that's too ugly...

Well, I suggest simply disabling the tests if you don't want those huge packages to be installed.

ruro commented on 2023-07-30 08:06 (UTC)

@Henry-ZHR the responsibility of package maintainers is to ensure that the software is built, installed and configured "correctly". The purpose of the check step is to verify some basic assertions about the built software. Stuff like "the built binary runs without immediately SEGFAULTing or complaining about missing .so files".

An exhaustive validation of all possible code paths and functionality combinations is the responsibility of upstream maintainers and is generally beyond the purview of check. To put it simply, the check step should test the validity of the PKGBUILD you have written, not the validity of the upstream source code. If the upstream package has an implementation bug that causes failing/flaky unit tests, the PKGBUILD check should still succeed (assuming the package still builds successfully).

Additionally, I would argue that validating compatibility with ALL opt-depends is overkill in this case. I'll admit, optional dependencies are a bit of a grey area, but in this case since the opt-depends include huge packages like tensorflow, torch, jax etc, I would argue that installing all of them by default just for some sanity checks is horrible UX.

Henry-ZHR commented on 2023-07-30 02:07 (UTC)

@ruro According to ArchWiki, "it helps to make sure software has been built correctly and works fine with its dependencies"

I don't think we can "make sure it works fine with its dependencies" unless we run the full test suite

« First ‹ Previous 1 2 3 Next › Last »