[petsc-dev] Sean is going to love this

[Sean Farley]

Geoff Oxberry writes:

> On Jan 2, 2015 1:38 PM, "Sean Farley" <sean.michael.farley at gmail.com> wrote:
>>
>>
>> Geoff Oxberry writes:
>>
>> > On Jan 1, 2015 8:46 PM, "Sean Farley" <sean.michael.farley at gmail.com>
> wrote:
>> >>
>> >>
>> >> Jed Brown writes:
>> >>
>> >> > Geoff Oxberry <goxberry at gmail.com> writes:
>> >> >> Brew bottles were originally only used in situations where building
>> > from
>> >> >> source would take a long time, and under the assumption that most
>> > users are
>> >> >> interested in a "standard" build without any command-line options.
>> >> >
>> >> > The dependency model assumes that flags do not change the binary
>> >> > interface.  This relates to the two things hard in Computer Science:
>> >> > cache invalidation and naming things.  I think Homebrew is refusing
> to
>> >> > acknowledge that different binary interfaces need different "names".
>> >>
>> >> This is one of the major issues I had with homebrew.
>> >>
>> >
>> > Sean, I'm confused: doesn't MacPorts do something similar with portfiles
>> > and variants? If a user wishes to install a variant for which a binary
> is
>> > unavailable, that port variant is then built from source, correct?
>> > (Assuming the MacPorts configuration is set up accordingly, per
>> > https://trac.macports.org/wiki/BinaryArchives)
>>
>> I misunderstood what Jed meant, then. And yes, MacPorts variants does
>> the same (assume that the ABI is the same). This problem is one I've
>> seen with most (all?) package managers.
>>
>> The problem I had with homebrew (when I tried it) was that I couldn't
>> specify different variants easily (such as package+gcc48 vs
>> package+gcc49). Perhaps that has changed?
>
> `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).

This is probably going to devolve into a Homebrew vs. MacPorts
discussion ;-)

The only problem with using non-system compilers is with C++ because
clang++ is not ABI compatible with g++. You could use gcc just fine if
there was something to enforce the induced dependency graph.

With MacPorts, the installed package has a variant to signify its
compiler: petsc+gcc49 vs petsc+clang, so I can hack a way to activate
them all at once fairly easily. I didn't see a way that Homebrew changed
a package's name if a different compiler was used.

>> Recently, I tried to evaluate homebrew but stopped when I ran into
>> trouble with bash completion and the way it handles (or doesn't handle)
>> multiple python packages for different versions of python.
>
> 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.

Nope, nope, nope, nope. Using multiple package managers, including
the broken python ones is a suggestion that is dead on arrival. I sure
as shit don't want to remember the different commands to search for a
package with multiple managers (Python, Ruby, node, etc.). Plus, it
doesn't solve the issue with packages that depend on other packages not
in its system.