any scripts in /usr/games/bin are no longer wrapped correctly and cause a random script appearing there since _distutils-r1_wrap_scripts changed example is games-board/pychess which is in stable branch hardcoding the paths is not a good idea.
I don't understand what you mean by 'random script'. It just causes the script to be installed in /usr/bin.
That is not correct. I get a python2.6 script in /usr/games/bin/pychess.
(I'm on python@)
Yeah, looks like _distutils-r1_wrap_scripts doesn't really work when the scripts are not in PYTHON_SCRIPTDIR.
1. We could parse argv passed to distutils-r1_python_install. But that sucks real much since distutils has a lot of magic in that syntax we'd rather not reinvent. 2. We could just let distutils install wherever it wants and then use 'find' to find wherever files landed. This is a bit fragile though. With python-exec:2, the script install location and name finally matches whatever setup.py installs and therefore expects. If we implement (2), then we lose this benefit.
Oh, I wasn't able to reproduce since I had a sane GAMES_BINDIR set. @hasufell, please use python-single-r1 for this particular packages. There's no real reason why a game would be installed for multiple impls. In the meantime, we'll find out how to fix it.
(In reply to Michał Górny from comment #6) > > @hasufell, please use python-single-r1 for this particular packages. no.
(In reply to Julian Ospald (hasufell) from comment #7) > (In reply to Michał Górny from comment #6) > > > > @hasufell, please use python-single-r1 for this particular packages. > > no. Rationale? DISTUTILS_SINGLE_IMPL kills your kitten?
(In reply to Michał Górny from comment #8) > (In reply to Julian Ospald (hasufell) from comment #7) > > (In reply to Michał Górny from comment #6) > > > > > > @hasufell, please use python-single-r1 for this particular packages. > > > > no. > > Rationale? DISTUTILS_SINGLE_IMPL kills your kitten? No, you have to give ME a rationale why I should not support multiple implementations. The fact that the eclass is currently broken for these packages is not one.
The package is an application and its Python modules are practically private. It is not a dependency of any other package. There's no real benefit of having multiple copies of the same file for a regular user. That's python team policy. That said, I admit that there's a bug in the eclass. It will be fixed once one of us has enough time to find a proper solution. Feel free to provide a patch. You don't need to terrorize us by forcing the users to hit the issue.
(In reply to Michał Górny from comment #10) > You don't need to terrorize us by forcing the users to hit the issue. I'm sorry, but I feel terrorized by unstable eclasses, random changes in their behavior and maintainers who don't communicate/test very well.
(In reply to Michał Górny from comment #10) > The package is an application and its Python modules are practically > private. It is not a dependency of any other package. There's no real > benefit of having multiple copies of the same file for a regular user. > That's python team policy. > I have no idea how users intend to use the packages I provide. I try not to assume too much about it. I provide the maximum of features to satisfy both users, hackers, developers and whoever may use this package in whatever way while trying to not make it overcomplex for the user. Most people only have one python2 and one python3 implementation installed. So the majority of users will not have multiple copies anyway. That said, I don't know what a "regular" gentoo user is.
We have offered a workaround for what we acknowledge to be a bug in the eclass. There is nothing more we can do to help solve this problem in the immediate future. Let's keep the discussion of terrorism to a minimum here.
Fixing this for python-exec:0 should be pretty straightforward. For python-exec:2, it's much harder. We definitely want setup.py to get the final script location (for any potential in-package use) rather than some random path given in ebuild. So far, I can't see other solution than: a) parsing command-line arguments given to setup.py during install, b) adding an environment variable that would override the install path. I think a) is a better solution here since it doesn't require specifying the same information twice. It would require some knowledge on how exactly distutils parses the arguments though.
Patch sent to the ml for review. Please test.
(In reply to Michał Górny from comment #15) > Patch sent to the ml for review. Please test. please attach it here as well, I'm not subscribed and gmane breaks patch syntax
Created attachment 361402 [details, diff] Patch rev1
(In reply to Michał Górny from comment #17) > Created attachment 361402 [details, diff] [details, diff] > Patch rev1 tested on all games reverse deps, seems to work
a few more random tests on vboxgtk trash-cli elogv gentoopm layman smart-live-rebuild keepnote jedi simplegui zfec ninja-ide tahoe-lafs pybugz seemed to work (those don't override scriptdir)
+ 22 Oct 2013; Michał Górny <mgorny@gentoo.org> distutils-r1.eclass: + Support installing Python scripts with custom --install-scripts argument. Bug + #487788.
