Table-flip of the day:
Table-flip of the day:
I want to maintain a small website, just a couple of static pages and a form. I ask a friend what would be best, he goes "Jekyll" and looking at it, it looks like a reasonable solution. Alright, let's install it.
Requires: Ruby 2.2.5 and RubyGems. Well, foo, Mac OS X Sierra only has 2.0.0. I guess I'll go and install a newer version.
How to install Ruby: Either use a third-party tool or compile from sources. Not wanting to dive too deeply into more installations, I try compiling. Works pretty well (I do like configure.in), except it cannot compile the gdbm and openssl extensions. This makes the tests fail.
So what's with OpenSSL? Turns out Mac has OpenSSL 0.9.8 but Ruby wants at least 1.0. How do I fix this? All the threads I see about it talk about using RVM, so let's give that a change.
How to install RVM:
\curl -sSL https://get.rvm.io | bash -s stable
ARE YOU FRIGGING INSANE? You want me to just download and execute something that might have been uploaded a minute ago with who knows what hacks? No way.
Ah, good: A more secure installation is available - by using gpg to verify the download. Which I don't have installed. And it still just downloads and executes whatever the newest thing is. No "stable version"?
Oh, but there's also this other other package management system. No, not rbenv, that's the other other other one. Homebrew. Because that's what everybody and their kid brother does when it comes to package management system. Because package management is such a simple task that anyone can do it.
Ok, ok, let's try homebrew, seems to be the Mac OS standard. Here's how:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Again? Really?
Ok, I'll just jump on Github and see if there's a numbered version so I can have at least some semblance of having someone try out the code before me. Nope, no tags or branches, but the latest change is 14 days old, so I'll chance it. But I'll growl at it while it runs to make sure it behaves.
It finished fairly quickly (yay 100Mbit fiber connection), and running brew install ruby was painless (and even put little🍺 in the output. Cute.) Unfortunately, now I have /usr/bin/ruby and /usr/local/bin/ruby. Any bets on how long before they start fighting each other?
So for Jekyll I just run
brew install jekyll
and it chews for a bit, then finishes. Oh, wait, the quickstart guide also wanted bundler. Let's do that next:
$ /usr/local/bin/gem install bundler
Fetching: bundler-1.16.1.gem (100%)
bundler's executable "bundle" conflicts with /usr/local/bin/bundle
Overwrite the executable? [yN]
No, it's not that installing jekyll also installed the bundler gem. It just is already there. Should I yes or should I no? Who knows? I'll take no for now. brew doesn't seem to know bundler. This other bundle executable was installed today as part of Ruby. I'll forge ahead with the "quick" start.
Nope, jekyll doesn't like this bundler. Overwriting the executables instead and rerunning jekyll new myblog:
Conflict: /Users/larsrc/Sites/myblog exists and is not empty.
Thanks, jekyll, for creating just enough of the blog to give an error on the next try before dying and not cleaning up. Nuke the dir and try again:
$ jekyll new myblog
Running bundle install in /Users/larsrc/Sites/myblog...
Bundler: The dependency tzinfo-data (>= 0) will be unused by any of the platforms Bundler is installing for. Bundler is installing for ruby but the dependency is only for x86-mingw32, x86-mswin32, x64-mingw32, java. To add those platforms to the bundle, run `bundle lock --add-platform x86-mingw32 x86-mswin32 x64-mingw32 java`.
Bundler: Warning: Your Ruby version is compiled against a copy of OpenSSL that is very
Bundler: old. Starting in January 2018, RubyGems.org will refuse connection requests from
Bundler: these very old versions of OpenSSL. If you will need to continue installing gems
Bundler: after January 2018, please follow this guide to upgrade:
Bundler: http://ruby.to/tls-outdated.
Bundler: Fetching gem metadata from https://rubygems.org/...........
Bundler: Fetching gem metadata from https://rubygems.org/.
Bundler: Resolving dependencies...
Bundler: Bundler could not find compatible versions for gem "ruby":
Bundler: In Gemfile:
Bundler: ruby
Bundler:
Bundler: jekyll (~> 3.7.0) was resolved to 3.7.0, which depends on
Bundler: ruby (>= 2.1.0)
So my openssl is going to start having trouble, maybe, sometime this month. Swell.
And it took about 15 minutes before the two versions of ruby started fighting each other. Grand.
And why is fetching the 'ruby' gem part of creating my blog? Why?
Adding /usr/local/bin to the path while running jekyll new myblog worked, and finally I was able to serve a static page.
Took about two hours for a seasoned (or at least somewhat salty) programmer with only a slight dose of paranoia to get through the "quick" start, adding at least two new package management systems on the way, if not three.
Extra package management systems are a scourge upon humanity. They bring nothing good. One package management system per OS, not per language and framework and container and app and whatnot. I swear, they're as bad as javascript frameworks (and often go together with them).
I want to maintain a small website, just a couple of static pages and a form. I ask a friend what would be best, he goes "Jekyll" and looking at it, it looks like a reasonable solution. Alright, let's install it.
Requires: Ruby 2.2.5 and RubyGems. Well, foo, Mac OS X Sierra only has 2.0.0. I guess I'll go and install a newer version.
How to install Ruby: Either use a third-party tool or compile from sources. Not wanting to dive too deeply into more installations, I try compiling. Works pretty well (I do like configure.in), except it cannot compile the gdbm and openssl extensions. This makes the tests fail.
So what's with OpenSSL? Turns out Mac has OpenSSL 0.9.8 but Ruby wants at least 1.0. How do I fix this? All the threads I see about it talk about using RVM, so let's give that a change.
How to install RVM:
\curl -sSL https://get.rvm.io | bash -s stable
ARE YOU FRIGGING INSANE? You want me to just download and execute something that might have been uploaded a minute ago with who knows what hacks? No way.
Ah, good: A more secure installation is available - by using gpg to verify the download. Which I don't have installed. And it still just downloads and executes whatever the newest thing is. No "stable version"?
Oh, but there's also this other other package management system. No, not rbenv, that's the other other other one. Homebrew. Because that's what everybody and their kid brother does when it comes to package management system. Because package management is such a simple task that anyone can do it.
Ok, ok, let's try homebrew, seems to be the Mac OS standard. Here's how:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Again? Really?
Ok, I'll just jump on Github and see if there's a numbered version so I can have at least some semblance of having someone try out the code before me. Nope, no tags or branches, but the latest change is 14 days old, so I'll chance it. But I'll growl at it while it runs to make sure it behaves.
It finished fairly quickly (yay 100Mbit fiber connection), and running brew install ruby was painless (and even put little🍺 in the output. Cute.) Unfortunately, now I have /usr/bin/ruby and /usr/local/bin/ruby. Any bets on how long before they start fighting each other?
So for Jekyll I just run
brew install jekyll
and it chews for a bit, then finishes. Oh, wait, the quickstart guide also wanted bundler. Let's do that next:
$ /usr/local/bin/gem install bundler
Fetching: bundler-1.16.1.gem (100%)
bundler's executable "bundle" conflicts with /usr/local/bin/bundle
Overwrite the executable? [yN]
No, it's not that installing jekyll also installed the bundler gem. It just is already there. Should I yes or should I no? Who knows? I'll take no for now. brew doesn't seem to know bundler. This other bundle executable was installed today as part of Ruby. I'll forge ahead with the "quick" start.
Nope, jekyll doesn't like this bundler. Overwriting the executables instead and rerunning jekyll new myblog:
Conflict: /Users/larsrc/Sites/myblog exists and is not empty.
Thanks, jekyll, for creating just enough of the blog to give an error on the next try before dying and not cleaning up. Nuke the dir and try again:
$ jekyll new myblog
Running bundle install in /Users/larsrc/Sites/myblog...
Bundler: The dependency tzinfo-data (>= 0) will be unused by any of the platforms Bundler is installing for. Bundler is installing for ruby but the dependency is only for x86-mingw32, x86-mswin32, x64-mingw32, java. To add those platforms to the bundle, run `bundle lock --add-platform x86-mingw32 x86-mswin32 x64-mingw32 java`.
Bundler: Warning: Your Ruby version is compiled against a copy of OpenSSL that is very
Bundler: old. Starting in January 2018, RubyGems.org will refuse connection requests from
Bundler: these very old versions of OpenSSL. If you will need to continue installing gems
Bundler: after January 2018, please follow this guide to upgrade:
Bundler: http://ruby.to/tls-outdated.
Bundler: Fetching gem metadata from https://rubygems.org/...........
Bundler: Fetching gem metadata from https://rubygems.org/.
Bundler: Resolving dependencies...
Bundler: Bundler could not find compatible versions for gem "ruby":
Bundler: In Gemfile:
Bundler: ruby
Bundler:
Bundler: jekyll (~> 3.7.0) was resolved to 3.7.0, which depends on
Bundler: ruby (>= 2.1.0)
So my openssl is going to start having trouble, maybe, sometime this month. Swell.
And it took about 15 minutes before the two versions of ruby started fighting each other. Grand.
And why is fetching the 'ruby' gem part of creating my blog? Why?
Adding /usr/local/bin to the path while running jekyll new myblog worked, and finally I was able to serve a static page.
Took about two hours for a seasoned (or at least somewhat salty) programmer with only a slight dose of paranoia to get through the "quick" start, adding at least two new package management systems on the way, if not three.
Extra package management systems are a scourge upon humanity. They bring nothing good. One package management system per OS, not per language and framework and container and app and whatnot. I swear, they're as bad as javascript frameworks (and often go together with them).
Comments
Post a Comment