<p dir="ltr">On Jan 2, 2015 1:38 PM, "Sean Farley" <<a href="mailto:sean.michael.farley@gmail.com">sean.michael.farley@gmail.com</a>> wrote:<br>
><br>
><br>
> Geoff Oxberry writes:<br>
><br>
> > On Jan 1, 2015 8:46 PM, "Sean Farley" <<a href="mailto:sean.michael.farley@gmail.com">sean.michael.farley@gmail.com</a>> wrote:<br>
> >><br>
> >><br>
> >> Jed Brown writes:<br>
> >><br>
> >> > Geoff Oxberry <<a href="mailto:goxberry@gmail.com">goxberry@gmail.com</a>> writes:<br>
> >> >> Brew bottles were originally only used in situations where building<br>
> > from<br>
> >> >> source would take a long time, and under the assumption that most<br>
> > users are<br>
> >> >> interested in a "standard" build without any command-line options.<br>
> >> ><br>
> >> > The dependency model assumes that flags do not change the binary<br>
> >> > interface.  This relates to the two things hard in Computer Science:<br>
> >> > cache invalidation and naming things.  I think Homebrew is refusing to<br>
> >> > acknowledge that different binary interfaces need different "names".<br>
> >><br>
> >> This is one of the major issues I had with homebrew.<br>
> >><br>
> ><br>
> > Sean, I'm confused: doesn't MacPorts do something similar with portfiles<br>
> > and variants? If a user wishes to install a variant for which a binary is<br>
> > unavailable, that port variant is then built from source, correct?<br>
> > (Assuming the MacPorts configuration is set up accordingly, per<br>
> > <a href="https://trac.macports.org/wiki/BinaryArchives">https://trac.macports.org/wiki/BinaryArchives</a>)<br>
><br>
> I misunderstood what Jed meant, then. And yes, MacPorts variants does<br>
> the same (assume that the ABI is the same). This problem is one I've<br>
> seen with most (all?) package managers.<br>
><br>
> The problem I had with homebrew (when I tried it) was that I couldn't<br>
> specify different variants easily (such as package+gcc48 vs<br>
> package+gcc49). Perhaps that has changed?</p>
<p dir="ltr">`brew info $FORMULA` should supply all options specific to that formula. There is also syntax for specifying different compilers via the `--cc=$COMPILER`,  `--cxx=$COMPILER`, etc. switches. In general, I avoid using non-system compilers unless I have to, because I've been told it can lead to breakage (via various sources, also h/t Aron Ahmadia). </p>
<p dir="ltr">><br>
> Recently, I tried to evaluate homebrew but stopped when I ran into<br>
> trouble with bash completion and the way it handles (or doesn't handle)<br>
> multiple python packages for different versions of python.</p>
<p dir="ltr">I tend to avoid using Homebrew (or any other package manager) to install Python and Python packages unless absolutely necessary, because it can be messy. I tend to use pyenv to manage any Python installations for scientific or development work. I haven't used the bash completion features of Homebrew much, so I can't speak to that point.</p>