[55961] trunk/dports/python

[Ryan Schmidt]

On Aug 23, 2009, at 07:04, Jonas Bähr wrote:

> Am 22.08.2009 um 22:25 schrieb Ryan Schmidt:
>
>> On Aug 22, 2009, at 14:13, Jonas Bähr wrote:
>>
>>> 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.
>
> Hmm.. That's interesting, because it worked flawless here; my R is / 
> usr/bin/R.

Ok, then that's why it worked. The default binpath does of course  
include /usr/bin, since /usr/bin includes tons of essential commands  
without which most software could not be built.

It is pretty improper for a third-party tool to install itself into / 
usr/bin, though. That directory should be reserved for the OS vendor.


> I've just checked my macports.conf and there is indeed no binpath  
> entry. When was this introduced in the default config? I've never  
> touched mine, and the header sais:
> $Id: macports.conf.in 31197 2007-11-18 06:06:14Z jmpp at macports.org $

http://trac.macports.org/changeset/36127

If you do not specify binpath, the default (see below) is used.


>> The R port presumably requires a gcc port because it cannot be  
>> built with the gcc Apple provides.
>
> indeed, apple's gcc does not provide a fortran77 compiler. I didn't  
> say these dependencies are useless, just that they are quite heavy;  
> and I assumed that the resulting R won't even be used if the custom  
> R comes first in PATH, like in my installation.

Ah, but if you have not changed the binpath then the custom R path  
does not come first in your installation. :) The default binpath is:


${prefix}/bin:${prefix}/sbin:/bin:/sbin:/usr/bin:/usr/sbin:$ 
{x11prefix}/bin


http://guide.macports.org/chunked/internals.configuration- 
files.html#internals.configuration-files.macports-conf


(${x11prefix}/bin goes away with MacPorts 1.8.0.)


>> 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.
>
> I'll file a ticket for a noX11 variant for the R port.

FYI the name we've standardized on for such a variant is "no_x11".


>> 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.
>
> Ok then, I'll replace the variant with a comment in the Portfile so  
> that people who know what they are doing can manipulate the  
> Portfile to continue using their R installation:
> ---------8<---------8<---------
> # To continue using your custom R installation instead of MacPorts' R,
> # you have to remove this dependency line and make sure that your R
> # is in MacPorts' binpath, see your macports.conf for details.
> ---------8<---------8<---------
> Is that a compromise everybody can live with?

Perhaps....

But again what were the advantages of using the non-MacPorts R, aside  
from your concerns over the number of dependencies and the build  
time? You said it could be customized and the MacPorts R port could  
not. In what ways?