| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Suggested-by: Gesh <gesh@gesh.uni.cx>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Update pkgver
- Update source URL (project has been moved to PyPA)
- Sort dependencies alphabetically
- Update `pip-api` comment (package has been updated to 0.0.22)
- Remove outdated `python-cachecontrol` comment (package has been
updated to 0.12.11)
- Add missing `python-rich` dependency
- Remove `python-packaging` dependency (declared upstream but already
satisfied through `python-pip-requirements-parser`)
|
|
|
|
The `flit` command performs some up-front validation before it actually
builds the package. This is intended for upstream project maintainers
so they have a chance to learn about issues before they proceed to cut
a release.
Once a package is released, people who consume the package (which
includes package repository maintainers) are assumed to be mainly
interested in getting the already-released package to build. Therefore,
they may simply want to run the build backend without caring about
up-front validation. That’s what the `build` command does: invoke the
suitable build backend, which in the case of `flit`, doesn’t run the
validation steps.
See discussion in [1].
[1]: https://github.com/pypa/flit/issues/580
CC: Thomas Kluyver <thomas@kluyver.me.uk>
CC: William Woodruff <william@yossarian.net>
|
|
According to the wiki, the preferred way to package a Python artifact
is to build a wheel. [1]
This basically produces a tree of .py files with a bit of metadata,
ready to use.
Intermingled with those .py files, it also produces a __pycache__
directory containing .pyc files. The documentation says that those
contain Python bytecode, which in turn is tightly coupled to the
specific VM that was used to produce them [2]. In other words, Python
bytecode is architecture-independent, but effectively tied to a
specific version of the Python runtime, for example 3.10. [3]
Keep the .pyc files because:
1. According to The Arch Way, things should be simple. The simplest
thing to do is to not care about .pyc files, and just leave
them in, just like upstream does.
2. Installing a wheel to a `pkgdir` already ties the package to a
specific Python version anyway, for example due to the fact that
the `site-packages` hierarchy is version-specific.
So the .pyc files are safe to use, regardless of architecture.
3. For most AUR users, the target architecture is identical to the
build architecture.
[1]: https://wiki.archlinux.org/title/Python_package_guidelines#Standards_based_(PEP_517)
[2]: https://docs.python.org/3/glossary.html#term-bytecode
[3]: https://stackoverflow.com/q/7807541
|
|
|
|
|
|
|
|
|
|
Add missing python-pip-api dependency bump
|
|
|
|
|
|
|
|
|
|
|
|
- Confirm that `pip-audit` actually requires `pip-api` v0.0.23 or
higher; Arch’s community package (v0.0.18) causes errors but
manually building pip-api v0.0.23 fixes the errors.
- Add comments
|
|
|
|
|