Package Details: flit 2.1.0-3

Git Clone URL: https://aur.archlinux.org/flit.git (read-only, click to copy)
Package Base: flit
Description: Simple packaging tool for simple Python packages.
Upstream URL: http://flit.readthedocs.io
Licenses: BSD
Submitter: flying-sheep
Maintainer: flying-sheep
Last Packager: flying-sheep
Votes: 5
Popularity: 0.065803
First Submitted: 2017-11-27 12:37
Last Updated: 2019-12-12 10:12

Latest Comments

flying-sheep commented on 2020-01-15 22:24

Should be fixed in install-wheel-scripts 1.1

Yeah, pip does so much that I didn’t want to supply like 4 different flags to make it maybe behave like it should in our case. If you get it wrong it’ll try to uninstall your system packages or so. I’m not entirely sure if the recommended commandline in the wiki is correct in every case.

The reason all my non-compiled python packages use wheels is because they’re simple. They’re just archives containing python source code, and you don’t need to run any maybe buggy python code in setup.py to install them, making the install faster (often also because the wheels are smaller than source tarballs).

aswild commented on 2020-01-15 21:21

This then picks up e.g. "python3" from an activated virtualenv, and fails:

This is exactly the sort of problem that using homebrew methods (install-wheel-scripts) rather than standard tools (pip install) can cause.

Edit: On the other hand, after reading more of the comments on https://wiki.archlinux.org/index.php/Python_package_guidelines it seems like pip can indeed be kind of janky too.

Using the sdist's setup.py compatibility script doesn't generate the flit launcher script because it pulls in distutils rather than setuptools, and there's circular dependency issues with flit_core that basically force wheels to be used. So idk anymore, besides just ditching flit personally until the ecosystem is more mature.

blueyed commented on 2020-01-15 11:41

/usr/bin/flit is:

#!/usr/bin/env python3
from flit import main
main()

This then picks up e.g. "python3" from an activated virtualenv, and fails:

Traceback (most recent call last):
  File "/usr/bin/flit", line 2, in <module>
    from flit import main
ModuleNotFoundError: No module named 'flit'

I think it should be "/usr/bin/python" in the shebang.

flying-sheep commented on 2019-12-12 10:16

Pip has a lot of implicit, hard to reason-about behaviors. Wheels should just be extractable and work, except for entrypoints.

Also pip seems to fixup permissions, which papers over a bug in flit that led to those permission problems. I fixed them.

mr_trouble commented on 2019-12-11 22:56

Anyone else having read permissions issues after the last update? Updated manjaro today and the directory has this:

ls /usr/lib/python3.8/site-packages/flit-2.1.0.dist-info/ -al

total 40

drwxr-xr-x 2 root root 4096 Dec 11 14:53 .

drwxr-xr-x 185 root root 16384 Dec 11 14:53 ..

-rw------- 1 root root 34 Dec 11 14:12 entry_points.txt

-rw-r--r-- 1 root root 1525 Dec 11 14:12 LICENSE

-rw------- 1 root root 3871 Dec 11 14:12 METADATA

-rw------- 1 root root 2326 Dec 11 14:12 RECORD

-rw------- 1 root root 81 Dec 11 14:12 WHEEL

If I install flit via pip, the permissions are correct.

aswild commented on 2019-12-04 04:48

What's the reason for the new unzip install-wheel-scripts install method over "pip install"? Installing from a wheel doesn't require flit to already be installed, so there's no bootstrap problem.

I replaced the package() function with 'pip install --compile --no-deps --ignore-installed --root="$pkgdir" "$_wheel_core"' (and the same for $_wheel_cli) and the package looks fine.

Using pip install not only avoids hacks around the /usr/bin/python3 symlink, it also enables precompiling all the .pyc files like normal Arch python packages.