#... python_replicate_script "${D}"/"${GAMES_BINDIR}"/launch-doomsday installmodules() { # relocate snowberry module directory recursively into site-packages python_domodule "${D}/${GAMES_DATADIR}"/${PN}/snowberry # hack around improper path handling sed -i \ -e "s:os.chdir.*$:os.chdir('$(python_get_sitedir)/snowberry'):" \ "${D}"/"${GAMES_BINDIR}"/launch-doomsday-${EPYTHON} || die ^^^^^^^^^^^ } python_foreach_impl installmodules Not that any specific fix comes to my mind right now but please keep this open for reference.
How is that a bug?
(In reply to Julian Ospald (hasufell) from comment #1) > How is that a bug? It's touching internals. Things you aren't supposed to touch nor rely on. We're likely going to break it in a few days or weeks from now.
What kind of internals? I don't use internal functions.
You're making assumption about how will wrapping work. You're only guaranteed that 'launch-doomsday' will be accessible where you want it, and that it will respect implementation choices. You are not allowed to assume about location of wrapped scripts.
If you mess with your API, you have to fix the consumers. If you break this package by eclass changes, I will revert it to the old python eclass.
(In reply to Michał Górny from comment #4) Instead of framing it as people doing something wrong and using eclass internals, you could simply state that the eclass behavior may change soon. No need to put people on the defensive. End of the day, we are all just trying to make stuff work with the tools we are given.
FYI: I've forced python-exec:0 in the ebuild now. We will probably revisit this near python-exec:2 going stable, so please keep the bug open.
Made it compatible with python-exec:2.
