pacaur/makepkg uses virtualenv when installing Python packages

[blueyed]

Usually Python packages use python in their PKGBUILD, which results in any
activated virtualenv to be used, e.g. from pep257:

package() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  python setup.py install --root="${pkgdir}" --optimize=1

  install -m 755 -d "${pkgdir}/usr/share/licenses/${pkgname}"
  install -m 644 -t "${pkgdir}/usr/share/licenses/${pkgname}" LICENSE-MIT
}

I think a fix for this would be to explicitly set PATH before calling makepkg to some whitelisted/verified setting, which could be made configurable or prefix PATH with /usr/bin explicitly (which would also pick up the system python).

Given that makepkg already mangles PATH for distcc and ccache in run_build, I could imagine having the fix there instead?!

See also https://aur.archlinux.org/packages/aws-cli#comment-527611, where I've initially reported this for aws-cli:

Message from pacaur -S:

warning: directory permissions differ on /tmp/
filesystem: 1777 package: 755

To reproduce:

1. virtualenv /tmp/env
2. source /tmp/env/bin/activate
3. pacaur -S aws-cli

pacman -Ql aws-cli will then show that the files are installed into /tmp/venv.

[rmarquis]

This is hardly a pacaur bug, as this would happen when using makepkg manually. Please report upstream to makepkg/pacman developers.

As a workaround, you might be able to set PATH explicitly in the pacaur config file, since it is sourced before any operation.

[blueyed]

Thanks for your reply/confirmation.

I've reported it on pacman-dev at: https://lists.archlinux.org/pipermail/pacman-dev/2016-January/020764.html

[blueyed]

Allan says in https://lists.archlinux.org/pipermail/pacman-dev/2016-January/020765.html:

makepkg is working as specified.

So, please consider re-opening and addressing it in pacaur.

I am using this workaround in /etc/xdg/pacaur/config currently:

PATH=/usr/bin:$PATH

[rmarquis]

Well, if makepkg works as specified, so does pacaur. Nothing I have to fix here.
If Allan considers it is the user responsibility to handle python env, so do I.

Edit: See Allan's answer, which fully makes sense.