So now that #bundler 2.x is here and now, should we add just `bundler` to our development dependencies, constrain it to `>= 1.0, < 3`, or `~> 2.0`, or `~> 1`?
While I'm kind of glad Apple finally decided to pick a direction to go in, this move is likely going to disrupt Homebrew which relies on system Ruby; and they can't rely on ruby-build/ruby-install because those in turn rely on homebrew. I suppose this shift is going to finally increase demand for precompiled releases of scripting language runtimes that can be extracted into `/usr/local`. I doubt that Apple will be generous enough to maintain their own precompiled packages of Perl, Python, Ruby.
I have been saying for years now that macOS is no longer a developer friendly platform (unless you work entirely in XCode). This news about Apple removing Perl, Python (2.7), and Ruby, might just be the final nail in the coffin. Each year I watch developers on $birbsite struggle to workaround the issues in the latest macOS release in order to setup a *nix-style development environment, all of which can easily be installed on Linux/FreeBSD with one or two package manager commands.
Wait, did `load` always search `$LOAD_PATH` for the file or was this added at some point? I thought it always expected absolute or paths relative to the current working directory?
Who's idea was it to put rake tasks in `.rake` files? This prevents `require` from being able to find/load them. Instead you need the full path to the files in order to `import` them, which gets ugly when the `.rake` files are in another gem...
I like how cookiecutter uses Liquid both in file/dir names and file bodies. While it's harder to register new Liquid functions, it does prevent arbitrary nasty code from hiding in templates. Although, the Ruby ecosystem is very familiar with ERb. Are there use-cases where ERb can do things that Liquid cannot?