[55961] trunk/dports/python

[Ryan Schmidt]

On Aug 22, 2009, at 14:13, Jonas Bähr wrote:

> Am 22.08.2009 um 18:03 schrieb Rainer Müller:
>
>> On 2009-08-22 17:57 , Ryan Schmidt wrote:
>>> On Aug 22, 2009, at 06:43, jonas at macports.org wrote:
>>>> +depends_lib         port:R
>>>> +
>>>> +variant custom_r description {Use a custom R installation instead
>>>> depending on macports' R} {
>>>> +    depends_lib-delete port:R
>>>> +}
>>>
>>> Why this? Is there a good reason why someone could not use the
>>> MacPorts R and would need to install their own? MacPorts policy is
>>> generally to use MacPorts versions of things only.
>>
>> Especially if nothing else is changed, this would not find another
>> installation of R as MacPorts does not search outside of the  
>> prefix. But
>> if R is not even required for building, this should be depends_run  
>> instead.
>
> R is needed to build and run. The install script looks for "R" in  
> PATH, that's all.
>
> The rational behind the custom R is to lighten the dependencies for  
> the user. The R-Project provides very good customizable installer/ 
> binaries for Mac OS X. MacPorts's R port however can't be  
> customized at all and pulls in a complete gcc plus xorg. In my eyes  
> it's much more convenient for a user who already uses R to continue  
> to use his installation and install rpy2 within 5 minutes instead  
> of spending 6 hours compiling xorg, gcc, and an other bunch of  
> dependencies for nothing. If the user's R comes in PATH before  
> macports R, it won't be used anyway.

MacPorts does not use your $PATH at build time. It uses the value of  
binpath in macports.conf. So for this to work a user would at least  
have to add the location of their binary installation of R to the  
binpath, and maybe also to their runtime PATH.

The R port presumably requires a gcc port because it cannot be built  
with the gcc Apple provides.

There are many many ports in MacPorts for software that needs xorg.  
They will all cause various xorg ports to be installed. That is not a  
reason not to use them.

It is not the MacPorts way to use a user's software that was not  
installed with MacPorts. MacPorts is a package management system. It  
is supposed to manage your packages. But it cannot do that if you  
allow ports to use software that is outside of MacPorts.

It would be best to remove the custom_r variant and make the port  
always use the MacPorts R port. If the R port does not provide all  
the options a user of R would expect, please file tickets requesting  
the R port be enhanced in whatever ways necessary.