data_files install in setup.py

[RuRo]

Can you explain, why are you using the data_files kwarg here? Providing an empty string as a path to data_files seems to install them into /usr/README.rst, /usr/LICENSE, /usr/lazyasd-py2.py and /usr/lazyasd-py3.py for a system-wide install, which is a really weird location IMO. Are these files even needed for an install? Maybe you meant to add them to MANIFEST.in?

[scopatz]

This is so that these files are installed into the tarball. Happy to have any improvements here!

[RuRo]

My understanding is that you should use package_data or MANIFEST.in for that (which you are already using). You are just missing the include_package_data=True option. Installing files straight into /usr is not acceptable in my opinion.

[scopatz]

Yeah, the intent is not to install directly into /usr. I am not sure how you are installing such that it is happening that way

[RuRo]

python setup.py build
python setup.py install --skip-build --root="${fakeroot}" --optimize=1

Where fakeroot is the directory, which the package manager has provided as the "install" directory. This is how 99% of packages are installed, using distro package managers on Arch-based systems.

So if fakeroot is /tmp/tmp.6kzs1REw1o, this command will create the /tmp/tmp.6kzs1REw1o/usr/lib/python3.8/site-packages/ directory and install the packages there. However, data_files directive will also place the files in /tmp/tmp.6kzs1REw1o/usr/LICENSE etc.

It seems, like setuptools/distutils support for single file packages is very limited/broken.

[scopatz]

I thought the prefered method these days is to use pip install .

[RuRo]

If you mean pip install . as in sudo pip install . then most definitely not, and there are countless people, that would shout at you for having the audacity to even consider this as a viable option. smh

If you mean as in pip install --user ., then this is the 'preferred' method only if you are a developer and no system package needs this package as a dependency.

[scopatz]

No, I thought that you were only supposed to run pip install and that setup.py install was deprecated

[RuRo]

Well, I am not an expert on the matter, but greping over my installed PKGBUILDs for pip install yielded 1 result, while greping for python setup.py install gave something like 40 results. Also, I just tried using pip install --root=${fakeroot} . in the same way, that you would use python setup.py install --root=${fakeroot} and instantly ran into this issue.

Edit: Okay, so you can install to fakeroot with pip, but there are quite a lot of gotchas and workarounds involved.

Warning: Use of pip and/or wheel packages is discouraged in favor of setuptools source packages, and should only be used when the latter is not a viable option (for example, packages which only come with wheel sources, and therefore cannot be installed using setuptools).

[scopatz]

In any event, I am happy to merge a PR with a fix here!

[RuRo]

I am not 100% sure, how exactly are you building the tarball, so I can't be 100% sure, whether any potential PR might break your current distribution method. I am assuming you are using python setup.py sdist?

Have you considered dropping python 2 support, since it has reached its EOL? It seems to me like most of the problems here stem from the need to select py2 or py3 version, which is only known during install. Without this, you could make the package zip_safe and just distribute a bdist/wheel/egg with appropriate metadata (LICENSE and README) instead of a source dist.

If that isn't an option, have you considered something like

import sys
if sys.version.major < 3:
    from .py2 import *
else:
    from .py3 import *

[gforsyth]

If you mean pip install . as in sudo pip install . then most definitely not, and there are countless people, that would shout at you for having the audacity to even consider this as a viable option. smh

If you mean as in pip install --user ., then this is the 'preferred' method only if you are a developer and no system package needs this package as a dependency.

pip install . is the preferred method of installing a package locally -- Arch is a bit of an outlier here because it's a rolling distro, for many users the general rule is "don't touch system Python".

PRs are welcome to fix this issue. It's also probably worth checking on the PKGBUILD in question to make sure it's doing the right thing.

[takluyver]

If I've understood this correctly, #13 should fix it.