Valet: HOMEBREW_PREFIX not being honoured.

Created on 24 Mar 2020  路  7Comments  路  Source: laravel/valet

there are 9 cases in valet where "/usr/local/" is hardcoded in, rather than honouring HOMEBREW_PREFIX

https://github.com/laravel/valet/search?q=%2Fusr%2Flocal&unscoped_q=%2Fusr%2Flocal

This means that any installation of homebrew outside of /usr/local (not so unusual when dealing with multiple toolchains) requires manual edits to the valet codebase.

This is such an easy thing to fix, I don't really know why it hasn't been done.

All 7 comments

not so unusual when dealing with multiple toolchains

For example?

For example when working on integrating unix utilities with homebrew, or when using non-brew unix toolchains that require /usr/local..

Regardless, as it is not the case that HOMEBREW_PREFIX is always /usr/local, it's a mistake to hard-bake such links in under that assumption.

Regardless

Point made. No need to justify it.

For example when working on integrating unix utilities with homebrew, or when using non-brew unix toolchains that require /usr/local..

While I realize "your" tooling makes complete sense to you, I've never run into a need to accommodate this, so I was hoping for actual examples in order to simulate and test proper actual functionality instead of only making changes that theoretically should "work".
Granted, I'd rather not taint my environment by adding toolchains I have no need of either.

As it seems I may have completely missed the point of your earlier question, I beg tolerance.
On my side, no offence was intended, no offence was taken.

It's easy enough to test by temporarily moving /usr/local, and then installing homebrew elsewhere. I'm sorry if I missed your point. I work on some different projects, eg. using hardware that depends upon hand rolled unix utilities that, by default, go to /usr/local. In the end, too many different systems consider it okay to stick their stuff into /usr/local. While brew does it's best to honour what it finds, it has been hard when brew-controlled software starts fighting with non-brew-controlled installs. This really shows its head when brew is out of date on a random library, or when I am working to fix a given hardware library, utility, or other unix-like widget.

Because /usr/local tends to get dumped on regularly on my workstation, I like to purge it completely every now and then, but it is quite a dramatic action to take. As I like brew, and also as it is a huge lump of stuff, I also like to keep it somewhere other than /usr/local.

But it means I have 3+ versions of php, python, g++, apache, nginx, and a load of other things.. That's why prefixes are so useful.

Does that help explain why I prefer not to use /usr/local for brew?

To be honest, I wonder if it is absolutely necessary to use homebrew within valet.
If there were a list of dependencies, then I could use a config file to set them up.
Meanwhile depending upon homebrew and it stinks for developers using other package managers.

Thanks for the clarification.
Apologies, I could have been a lot clearer in my initial post, which would have reduced the misunderstanding. I'll own that! :)

I have no objection to changing away from unnecessary hardcoding. As you say, it's a small and fairly clear change.

Are you interested in submitting a PR for this change? You're probably in a better situation to test it, as (reading between the lines) I imagine you've already been using the proposed changes already yourself. It's always better to PR changes that have been used in production :)

I'd support the PR and test it here as well.

yea - it will take me some time to create the PR, but I'm happy to do it in principle ;-D

This problem is solved in https://github.com/laravel/valet/pull/992

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dustinleblanc picture dustinleblanc  路  4Comments

marianvlad picture marianvlad  路  5Comments

TimOgilvy picture TimOgilvy  路  3Comments

hsleewis picture hsleewis  路  5Comments

idmahbub picture idmahbub  路  3Comments