tcl needs --disable-corefoundation

Ryan Schmidt ryandesign at macports.org
Sun Oct 11 18:59:48 PDT 2009


On Oct 11, 2009, at 19:40, Jack Howarth wrote:

>    The current behavior seems really confused. For example, if I have
> python25 and python26 installed but only python26 activated, I can
> install py25-setuptools with out errors being reported.

I don't know how that would be possible, since py25-setuptools depends  
on python25, by virtue of using the python25 portgroup.

$ port deps py25-setuptools
Full Name: py25-setuptools @0.6c9
Library Dependencies: python25

This means if you try to install py25-setuptools, and python25 is not  
installed, it will be installed first. Or if it is installed but  
inactive, it will be activated first. It should not be possible for  
the configure phase of py25-setuptools to begin unless python25 is  
installed and active.


> However, if I execute...
>
> sudo port install py25-pmw
>
> I get an error...
>
> DEBUG: Found Dependency: receipt exists for python26
> --->  Activating py25-pmw @1.3.2_1
> DEBUG: Image error: /opt/local/Library/Frameworks/Python.framework/ 
> Versions/2.6/lib/python2.6/site-packages/Pmw/__init__.py is being  
> used by the active py26-pmw port.  Please deactivate this port  
> first, or use 'port -f activate py25-pmw' to force the activation.
>    while executing
> "_activate_contents $name $imagefiles $imagedir"
>    (procedure "portimage::activate" line 56)
>    invoked from within
> "registry_activate $name ${version}_${revision}${portvariants}  
> [array get user_options]"
>    (procedure "eval_targets" line 21)
>    invoked from within
> "eval_targets activate"
>    invoked from within
> "$workername eval eval_targets $target"
>    (procedure "mportexec" line 85)
>    invoked from within
> "mportexec $workername $target"

That sounds pretty bad. It sounds like py25-pmw somehow decided it  
should use python26, which of course it shouldn't. Do you have  
python_select installed? If so, which python is selected? This  
"select" business has always seemed problematic to me, because some  
ports (perhaps py*-pmw among them) may use "python" instead of using  
the correct versioned executable like "python26" and it might  
therefore lead to an error like this if you were installing a python26  
module but python25 was "select"ed.


> If I follow the recommendation and execute...
>
> sudo port -f activate py25-pmw

It's not a recommendation! The "-f" flag should always only be used if  
you know what you're doing. Perhaps the message should be revised to  
read

"Please deactivate this port first, or use 'port -f activate py25-pmw'  
to force the activation if you know what you're doing."

The recommendation was to "deactivate this port first" but even that's  
not applicable here, since clearly a python25 module should not be  
installing anything into the python26 directories.


> I get errors...
>
> Warning: File /opt/local/Library/Frameworks/Python.framework/ 
> Versions/2.6/lib/python2.6/site-packages/Pmw/__init__.py already  
> exists.  Moving to: /opt/local/Library/Frameworks/Python.framework/ 
> Versions/2.6/lib/python2.6/site-packages/Pmw/ 
> __init__.py.mp_1255307467.
> etc.

That's a warning, not an error. It is informative to you, letting you  
know that because you requested the activation to be forced, the  
conflicting files were moved away. You may delete these moved files if  
you don't want them. They are now disconnected from any notion of  
having once belonged to any port, so MacPorts will not be cleaning  
them up for you.


> The logic of maintaining multiple pythons seem horribly convoluted  
> and very
> fragile (at least if you follow the recommendations in the error  
> messages).

Perhaps the error messages need to be revised to clarify what is and  
what is not a recommendation.


> Wouldn't it be better to just have any Portfile that needs access to  
> python25
> or python26, explicitly depend on it and, if not activated, allow  
> port to request
> for and implement the activation in real time during the build?

The current code should already be doing this. I cannot explain why it  
did not for you.




More information about the macports-dev mailing list