Develop on OSX - missing steps (ca-certificate)


(Hank G) #21

I can read the statement both ways hence my stated concern about it while caveating that I may be over-interpreting what was written.

With respect to getting rid of the non-Docker Mac guide, if we get rid of that could we at least put up a blog post we could refer to about how to bootstrap a macOS development environment. As a regular contributor that hopes to be a core member I’ll say I do do development on macOS bare metal as well as Linux. Total sidebar since this is a blog discussion, but just a suggestion, but since it directly impacts me I don’t mind doing the lifting on writing that sort of post. I’ll probably end up writing one for my personal blog anyway along with some others with respect to setting up RubyMine. Maybe we could cross post or something…


(Dennis Schubert) #22

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.


(Hank G) #23

Thanks for the clarification. I wouldn’t call it ranty. I’d call it thorough. I have not been following the Docker discussions so I’m glad integrating that into an IDE development environment has been considered. Based on previous IRC comments I thought I was the only one using an IDE :slight_smile: .

If by this you mean attaching the RubyMine debugger, yes I do this when debugging specs a lot. I want to do this when debugging the server but haven’t figured that out yet. I only dabbled trying to anyway but want to get back around to this eventually.