I do. In fact, not only primarily, but exclusively.
Still, the official installation guides will treat macOS as a Docker-only target, and as of right now, I don’t really have plans to offer non-Docker guides for macOS (obviously, they still will be available for Linux, so one can always have a look at that). There are many reasons for that, some of which are…
- macOS ships its own Ruby, which as of right now claims to be a
2.3.7p456. and if you follow Ruby, you’ll notice that there isn’t actually a 2.3.7p456, but rather an official 2.3.8. That’s because Apple is always a bit slow (some of their system components depend on Ruby), and thus end up manually patching older Ruby versions with security patches from newer releases. That’s fine, but that results in mac’s 2.3.7 not always behaving like a 2.3.7 should. This has caused us some issues in the past, and those are headachy.
- The default Ruby isn’t upgradeable, and even installing a gem requires
sudo privileges, because they get installed in non-user-writeable paths. As apple never really intended stuff like brew to happen, you can actually break Ruby in funny ways, like installing nokogiri with the default system ruby and a libxml installed via brew instead of the system’s libxml, which will cause the system ruby to crash randomly. And I’m not takling about meaningful crashes here, it literally just segfaults all the way.
- We tell people to install Ruby via RVM, but it often happens that something goes wrong or people don’t follow the instructions. On other systems, that’s not a big issue, because if RVM is not set up correctly, everything will just fail because diaspora’s script can’t find a ruby executable. On macOS, it silently falls back to the system ruby (because it’s still in
PATH, and you can’t remove it from PATH, because if you do, everything explodes. I’ve tried it). See the previous two points for why using the system ruby is horrible.
- How do we even tell people to install dependencies? Some folks use homebrew, some folks use macports, some folks do other things like compiling everything themselves. Ultimately, installing Ruby and building native extensions depends on those things, but loading paths may or may not be picked up, and thus result in various build errors hard to debug remotely.
The fun thing is that a bare metal installation isn’t even needed, anyway. If you followed our discussions around requirements for a development docker container, then you know we actually thought about a lot of things, including folks using RubyMine (it just happens we get supported by JetBrains, and thus, a lot of our team members use RubyMine). Because of that…
- when using the Docker setup, the sources actually are not encapsulated inside the container. Instead, you just run a normal
git clone on your machine, which you can happily add to your IDE and work from there. On starting diaspora via Docker, it live-mounts the sources into the container.
- Yes, that means that even live-reloading sources you edit in your IDE will be picked up by diaspora running inside Docker just fine.
- You can even use the start/stop/restart/run tests/whatever buttons inside your IDE. You only have to tell RubyMine to execute
./script/diaspora-dev exec bin/rails s instead of bin/rails s and even RubyMine’s runserver controls work just as you expect.
- Heck, even RubyMines spec-autorun works, if you tell it to run
./script/diaspora-dev exec bin/rspec instead of bin/rspec.
The only case where RubyMine-with-diaspora-inside-Docker will fail is if you try to use the step debugger, that ain’t gonna happen inside Docker, because it depends on being able to talk to the Ruby interpreter, and the debug library compiled on macOS doesn’t really understand the Linux binaries all to well. However, if that is a requirement, you know how Ruby works anyway, at which point you already have Ruby set up (either via RVM, but probably via chruby). At that point, diaspora behaves like any other boring old Rails application, and you get it running with bundle install and bin/rails server. In fact, RubyMinses default “Import this Rails app thingy, install Ruby and run it” works just fine, because RubyMine doesn’t really care about script/server and other diasproa specifics, but it actually does not need to.
This reply got a bit more ranty than I anticipated it to be, but while we are on it… If you don’t install the correct Ruby version beforehand, and import the project into RubyMine on macOS, Rubymine asks you if it should install Ruby via RVM for you. Nice feature, except for one thing: It passes some arguments into rvm, which causes RVM to recompile some parts using macOS native libraries. That’s fine, and they do that so they can use more advanced memory inspection during step debugging. However, captchas won’t work. So if you try to run diaspora in production env locally do debug this, you’ll end up banging your head against the wall. There are probably some other super-hidden gotchas, which is why I really, really, really like the Docker development env. It makes things predictable for everyone.
.