On Sun, Jan 4, 2015 at 6:34 PM, Sean Farley <sean.michael.far...@gmail.com> wrote:
> > Jed Brown writes: > > > Sean Farley <sean.michael.far...@gmail.com> writes: > >> 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. > > > > Uh, isn't this libc++ vs libstdc++ rather than clang++ vs g++? Note > > that merely mixing -std=c++11 code with a single compiler can be a > > problem. C++ repeatedly chooses language features that make binary > > compatibility difficult. > > Yes, a slip on my part. I meant libc++ vs libstdc++ not being ABI > compatible. > > >> 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. > > > > I agree with Sean that mixing package managers is a mess. Maybe if I > > lived in a self-contained Python-only world, but I don't. I want to be > > able to reliably install (and upgrade, remove, query) a package that > > depends on any subset of packages. That could mean mixing Python, > > Haskell, R, and Emacs packages. > > Exactly. > I also agree that mixing package managers is a mess. I still prefer it to manual installation in most cases. A single package manager solution would be best, but I have yet to see one effectively incorporate existing language-specific package ecosystems.