Best Practice Regarding Nested Package Management With Homebrew?

(Bryce Glover) #1

     Suppose one has installed Homebrew and used it to install multiple programming-language toolchains, each of which is includes its respective programming language’s own internal package manager meant for dealing with library dependencies. (Examples of such programming languages would include Ruby, Python, Perl, Rust, et cetera.) What is considered the best practice for having any one of any such a programming language’s package manager install packages system-wide without storing them somewhere inside the directory structure containing its toolchain, thus inviting Homebrew to wipe that programming language’s library package store clean when it updates said programming language?
     /usr/local/var seems like it might be a good place to point package managers other than Homebrew to store things. (I say that based on where MySQL stores its configuration and database files when installed via Homebrew even though that’s neither usually considered programming language beyond its being a query language nor a piece of software that even has an internal package manager for…well, I guess its equivalent of library dependencies would be plug-ins and extensions.) I could be wrong, though, as somewhere else might, perhaps, be better.

P. S.: Perhaps Homebrew could give users a hint to do this via some new caveats added to the relevant packages’ formulae? (I take it that, due to the Homebrew project’s preference to store patches upstream, having alternate configuration files distributed as part of bottles and added by formulas when they get invoked for from-source builds would be out of the question.)