Package Details: python-safetensors 0.5.2-1

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-2.0
Submitter: Henry-ZHR
Maintainer: envolution
Last Packager: envolution
Votes: 6
Popularity: 0.60
First Submitted: 2023-01-08 09:54 (UTC)
Last Updated: 2025-01-10 04:18 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4

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

ruro commented on 2023-07-29 22:39 (UTC)

You definitely shouldn't run the full test suite during check. This step is for checking whether the build process succeeded and that the system is compatible with the built package (minimal sanity checks), not for testing the correctness or the quality of the source code of the package (unit tests, regression tests, linting, etc).

Henry-ZHR commented on 2023-06-17 04:18 (UTC)

@matiasvlevi It should work now (although imperfectly)

Actually I think avoiding the tests is optimal because of the heavy dependency...

matiasvlevi commented on 2023-06-16 05:58 (UTC)

I had to disable pytest test in the PKGBUILD for the package to install correctly.

It seems like the tests weren't able to find the 'safetensors' package. Now that I skipped the tests, the package is available on my system.

This may need further investigation, avoiding the tests is not optimal.

« First ‹ Previous 1 2 3 4