Valet: Official support for Valet on Linux/Windows (now that Homebrew officially supports Linux/Windows)

[jalendport]

I'm curious: with the release of Homebrew 2.0.0 which officially supports Linux (and indirectly Windows via Windows Subsystem for Linux), is Valet for Linux/Windows a possibility? I can totally understand Adam's position in #568 (not a Windows or Linux guy either), but curious if Homebrew 2 makes any difference in that decision. I'm not _super_ familiar with the Valet codebase or with the changes implemented in Homebrew 2.0.0 so I'd be interested in hearing from people who know more than me 😄

[mattstauffer]

I think we'd have to get official volunteers committing to support each environment, and some pretty thorough testing from multiple folks on branches before we did that. And it would definitely be a 3.0 feature.

Not saying "no never", but Adam's point is definitely still true, even though he's not doing the majority of the day-to-day maintenance. I don't use Windows or Linux and don't care to maintain machines for testing, and I'm guessing that the biggest contributor right now, @drbyte, doesn't have time for that (he's busy enough just fixing everything for all the Mac users!)

So.. if people step up.. maybe? :)

[stefanobartoletti]

There is a fork named Valet Linux here https://github.com/cpriego/valet-linux

It has some problems and it seems that it is no longer actively maintained, but it pretty much works.

Maybe it could be a starting point.

[SamXDesc]

There is a fork named Valet Linux here https://github.com/cpriego/valet-linux

It has some problems and it seems that it is no longer actively maintained, but it pretty much works.

Maybe it could be a starting point.

I use everyday and works fine for me and my partners. I fully agree that can be a good starting point.

[rumansaleem]

It has some problems and it seems that it is no longer actively maintained, but it pretty much works.

It seems to work for me as well, but since I upgraded to my linux kernel to 5.0, I ran into problems with internet access.
I also believe that it can be a good starting point.

[matt-allan]

I've been looking into this because I recently switch to Ubuntu and I really miss Valet. Valet is also a nice option for beginners so it would be great if it worked across the major operating systems.

I personally don't want to use Homebrew for Linux -- I already have a perfectly good package manager :laughing:. I looked into valet-linux which seems to be actively maintained again but it has diverged significantly from Valet (280 commits ahead, 506 commits behind laravel:master) and there's enough code I can't easily review what it's actually going to do to my system.

The main issue with supporting Linux if you don't use Homebrew is you need to deal with ~6 different package managers and ~2 different service managers. This is a lot of work to test.

The rest of Valet doesn't really need to change between operating systems, so I've been wondering if it would be possible to add Linux support as an 'extension' rather than forking Valet. This would allow someone that uses that OS to actually maintain the extension.

Looking through the code it looks like these are the reasons Valet won't work on Ubuntu:

• Brew instead of apt/systemd
• Can't start dnsmasq without stopping systemd-resolve
• Uses /usr/local/ prefix on paths everywhere when Ubuntu uses / by default
• Uses pbcopy instead of xsel
• ngrok binary is for Darwin only
• PHP_OS check in compatibility.php
• permissions maybe? I think some commands will require sudo if you don't use /usr/local
• keychain paths for ssl certs

We should be able to change those things with only minor changes to Valet itself. Valet already supports extensions, so the extension could register container bindings to i.e. replace Brew.

I _think_ should be possible without noticeably increasing the maintenance burden on the core Valet maintainers. I'm planning on trying this approach with an Ubuntu/Debian extension to see if it works.

[jmarcher]

Hello, I'm the current maintainer of https://github.com/cpriego/valet-linux

As @matt-allan said, the projects diverged a lot, the project started focusing on Ubuntu (original repo was valet-ubuntu only) I forked the repo and abstracted the Ubuntu package manager and extended it for "all" package managers out there. The thing is, at the time we did this Homebrew was MacOS only, therefore a big portion of the code was refactored to work with native package managers.

I think a merge is not possible anymore, maybe some ideas could be extracted from the repo, but not much more.

I would love to see official support on Linux.

[mattstauffer]

@jmarcher Great, thanks! Would you say that modifying core Valet to work for Linux would be A) bad because your work would be wasted, B) good but an incredible amount of work, or C) good and only a modest amount of work?

Thank you!

[jmarcher]

@mattstauffer Hi Matt, I took a quick look over the code again, I think it could be done but I can not say it is going to be easy but not hard thou, MacOS and Linux are in a way very similar.
The problematic is that different Linux distros have different paths for config-, log- executable-files, this should be taken into consideration.

We officially support 5 major "flavours" of Linux: Ubuntu/Debian (APT), Arch/Manjaro(pacman), Fedora (dnf), Solus(eopkg) and Red Hat(yum)
(The package-managers are only for reference)

To be honest I did not tested (nor really used it at all) how well homebrew works on Linux and how widely used it is, I mean it is easy to install after all.

Another thing is the ngrok executable, we need to have one for linux and another one for MacOS.

[itguy614]

Just a thought for package management and configuration. Leverage Salt or some other state management system to perform package installation and configuration.

[jmarcher]

I mean as for a package manager, we should use brew that is the whole point, but an existing problem are service manager, Linux alone has a few, I do not know how MacOS manages the services, and I'm sure that Windows manages them pretty differently.