[Baypiggies] Novice Programmer Asking For Assistance

[Glen Jarvis]

Good summary. Thanks!

G

On Oct 23, 2012, at 8:56 PM, Ned Deily <nad at acm.org> wrote:

> In article <0ED37AE7-94C3-41F2-8B4F-C23D99087FC0 at glenjarvis.com>,
> Glen Jarvis <glen at glenjarvis.com> wrote:
>> I've had really good luck with MacPorts (I keep it clean and updated -- a 
>> very good habit).
>> 
>> But, what FUD does it get?
> 
> I was going to say start by looking at the home page of the project but 
> I see that it has apparently recently been changed.  ATM, you can still 
> get a feel for it by googlng; the cached title line is still there.
> 
>> Also, I've never had a reason to use HomeBrew -- 
>> what's its selling points?
> 
> Others can probably do a better job than I but I think the main 
> advertised advantages are that (1) Homebrew recipes are written in Ruby 
> and originally were more light-weight than the older and more 
> option-filled MacPorts port files (written in Tcl) and (2) Homebrew 
> recipe writers are encouraged to use OS X-supplied libraries and other 
> components whenever possible rather than supplying and building separate 
> versions of them as happens more often with MacPorts ports.  This is a 
> major philosophical difference.  Back in the early days of OS X before 
> Homebrew existed, this was less of an option, as fewer third-party 
> libraries were shipped in OS X and/or they tended to be more 
> out-of-date.  But even on the most recent OS X releases, there are still 
> some libraries that do not get updated to current versions by Apple for 
> various reasons: openssl and ncurses come to mind.  And, as Homebrew has 
> matured and more recipes added, it has had to resort to building more 
> and more stuff.  For instance, I believe it was the case that Homebrew 
> originally relied on the Apple-supplied system Pythons but it now does 
> provide its own Python recipe as MacPorts does.   Because MacPorts 
> usually tries to provide a more up-to-date and reproducible environment 
> by supplying more of the underlying libraries and other build 
> components, that has sometimes led to some ports taking a long time to 
> install because of all of their dependencies, in a few cases going as 
> far to build a whole new gcc as a dependency.  There are usually good 
> reasons for that: for instance, if the port requires gfortran support 
> which is not included in the standard Apple compilers supplied with 
> Xcode.  However, with many ports there are ways to limit the 
> dependencies if you really don't need all of the features of a port.   
> That's accomplished by looking at the port description and selecting a 
> different set of port variants, one of the less well-documented and 
> -understood features of MacPorts.  Also as more and more ports become 
> available as pre-built binaries from the project this aspect of MacPorts 
> should become more of a non-issue.   
> 
>> My macports are very clean and my /opt/local looks like a mini Linux file 
>> system. Can I use a new path for HomeBrew and use them in conjunction (i.e. 
>> is it relocatable)? What benefits would it give me over MacPorts?
> 
> I believe Homebrew by default installs its ports to /usr/local.  The 
> MacPorts project specifically warns against having installed potential 
> duplicates in /usr/local while installing MacPorts ports.  The reason is 
> that they know from long and bitter experience (MacPorts has been around 
> in one form or another for over 10 years and, btw, the project is 
> supported in a number of ways by Apple) that, despite their best efforts 
> to detect and patch the third-party configure scripts and Makefiles for 
> all the ports they support, many of them have hardcoded references to 
> /usr/local and can end up linking with unexpected versions of libraries 
> that may be the wrong version or built with different architectures or 
> OS X deployment targets.
> 
> If you are happy with MacPorts, I can think of no reason to migrate to 
> Homebrew.  And, likewise, if you are happy with Homebrew, then by all 
> means stick with it.   But it's not a good idea to mix them.  And the 
> advantages of one over the other are not as one-sided as some people 
> seem to think.
> 
> -- 
> Ned Deily,
> nad at acm.org
> 
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies