On 12/29/2011 09:06 AM, Michał Górny wrote:
> On Thu, 29 Dec 2011 08:50:11 -0500
> Mike Gilbert <floppym@g.o> wrote:
> 
>> On 12/29/2011 08:41 AM, Michał Górny wrote:
>>> On Thu, 29 Dec 2011 08:08:26 -0500
>>> Mike Gilbert <floppym@g.o> wrote:
>>>
>>>> This patch allows python_mod_optimize to be used in cases where a
>>>> different set of python modules is installed depending on the
>>>> python abi.
>>>>
>>>> For example, dev-python/feedparse-5.1 (not yet in the tree)
>>>> installs the _feedparser_sgmllib.py module only in python-3*.
>>>
>>> Could you paste some example on how it is supposed to be used?
>>>
>>
>> Sure. Borrowed from feedparser-5.1.ebuild in Progress:
>>
>> pkg_postinst() {
>>     python_mod_optimize -A "2.*" feedparser.py
>>     python_mod_optimize -A "3.*" feedparser.py _feedparser_sgmllib.py
>> }
>>
>> pkg_postrm() {
>>     python_mod_cleanup -A "2.*" feedparser.py
>>     python_mod_cleanup -A "3.*" feedparser.py _feedparser_sgmllib.py
>> }
> 
> Ok, now that I see it, I think you're inventing a really big hammer to
> get rid of a single mosquito.
> 

I don't think the hammer is really that big; it seems like a relatively
small extension to me. The code for checking ABI patterns is already
there, this just wires it up to a couple of additional functions.

I actually think it would make more sense to call python_mod_optimize
using python_execute_function, but I think that would require a
backward-incompatible API change.

> On the other hand, I don't think I can think of a good per-ebuild way
> to handle this. I'd rather start by pinging upstream not to pollute
> global namespace and install a package instead; even if it supposed to
> contain __init__.py only.
> 

That would take care of this specific package, yes. However, I still
think it would be nice to have a workaround available.