Skip to main content

perlbrew and mojolicious

I'm not a fan of the guys over at mojo but it's probably the better of the Perl micro-webframeworks out there. So I was curious if mojolicious was going to work with perlbrew.

The first thing I did was install perlbrew. There are several ways to do it. I decided upon the first option:
curl -Lk | bash

What I do not like about the above command is that the code is assumed to be good and safe. It would have been a little more helpful of the code were downloaded from CPAN.

Once the module was installed. I was directed to add a line to my .bash_profile and then restart my terminal session. Easy enough.

NOTE: I did not recall what the base version was so I edited the .bash_profile file again and commented out the line that I was instructed to include. Then I opened a new terminal session and executed the command:
perl -v

My default/host perl version was 5.12.3. And I wanted to install perl 5.16.0 the latest and current version of perl:
perlbrew install 5.16.0

Easy enough! At this point there was a message on the console that suggested a tail command that I could use to monitor the build. That was easy too. In the end it took about an hour or so and I had a working Perl 5.16.0. (feel the perlbrew doc for the interesting commands)

As a last step I wanted to see what was going to happen when I installed mojolicious, could it be installed in userspace, and which version was it doing to use. So I installed mojo:
curl -L | perl - Mojolicious

I omitted the 'sudo' that the mojo guys recommended and it installed fine. But now the proof needed to be in the pudding. I created a file:
use Mojolicious::Lite;
get '/' => {text => 'Hello World! ' . $] };

Notice that I added the $] to the message. This is going to append the Perl version number to the end of the hello world string. The good news is that when I ran the application:

and launched my browser, I received a message that told me I was using Perl version 5.16.0. Perlbrew was a success and so was Mojo.


  1. It has been a few months since I had any interactions with the mojo team but I thought I would submit a ticket to their system requesting that they specifically document the interaction with perlbrew. The response I received was:

    "Closing this issue since it doesn't appear to be a bug report or feature request. Please use the mailing list or IRC if you need help." -- Sebastian Riedel

    I recognize that teams can be inundated with stupid requests or even trolled into paralysis, however, my request was sincere. Until this person changes his apparent contempt for others I cannot and will not recommend mojo as a project.

    His twitter description:

    "Supervillain in the Perl universe..." -- Sebastian Riedel

  2. Cooler heads prevail:

    "Most professional Perl programmers already use perlbrew (including all our core devs), it is pretty much a community convention. You're welcome to contribute new documentation to the wiki, if it becomes popular it will get merged into core." — Sebastian Riedel

  3. Here is a list of alternative web frameworks:

  4. Perhaps your ticket was just awfully written? Here's the missing link to the full conversation.

  5. I do not disagree that maybe I could have been explicit but I'm not convinced that it would have yielded a different result.

  6. Looks like he specifically left out the part where Sebastian told him that he did not understand the request... classy!

  7. I don't even care about the full conversation, calling people out like that is wrong and invalidates your whole argument.

  8. Are you a troll or incompetent?

  9. I was sincerely trying to help the project. I'm not a mojo expert so I tried to point it out for someone who was so they could address. I'm not interested in anyone's negative and non productive attention this post has received.

  10. As I said in several replies to comments. This was a sincere attempt... (this comment stream is closed)

    Update: Larry Wall, father of Perl, said hubris and not asshole.


Post a Comment

Popular posts from this blog

Entry level cost for CoreOS+Tectonic

CoreOS and Tectonic start their pricing at 10 servers. Managed CoreOS starts at $1000 per month for those first 10 servers and Tectonic is $5000 for the same 10 servers. Annualized that is $85K or at least one employee depending on your market. As a single employee company I'd rather hire the employee. Specially since I only have 3 servers.

The pricing is biased toward the largest servers with the largest capacities; my dual core 32GB i5 IntelNuc can never be mistaken for a 96-CPU dual or quad core DELL

If CoreOS does not figure out a different barrier of entry they are going to follow the Borland path to obscurity.

UPDATE 2017-10-30: With gratitude the CoreOS team has provided updated information on their pricing, however, I stand by my conclusion that the effective cost is lower when you deploy monster machines. The cost per node of my 1 CPU Intel NUC is the same as a 96 CPU server when you get beyond 10 nodes. I'll also reiterate that while my pricing notes are not currently…

eGalax touch on default Ubuntu 14.04.2 LTS

I have not had success with the touch drivers as yet.  The touch works and evtest also seems to report events, however, I have noticed that the button click is not working and no matter what I do xinput refuses to configure the buttons correctly.  When I downgraded to ubuntu 10.04 LTS everything sort of worked... there must have been something in the kermel as 10.04 was in the 2.6 kernel and 4.04 is in the 3.x branch.

One thing ... all of the documentation pointed to the wrong website or one in Taiwanese. I was finally able to locate the drivers again: (it would have been nice if they provided the install instructions in text rather than PDF)
Please open the document "EETI_eGTouch_Programming_Guide" under the Guide directory, and follow the Guidline to install driver.
download the appropriate versionunzip the fileread the programming manual And from that I'm distilling to the following: execute the answer all of the questio…

Prometheus vs Bosun

In conclusion... while Bosun(B) is still not the ideal monitoring system neither is Prometheus(P).


I am running Bosun in a Docker container hosted on CoreOS. Fleet service/unit files keep it running. However in once case I have experienced at least one severe crash as a result of a disk full condition. That it is implemented as part golang, java and python is an annoyance. The MIT license is about the only good thing.

I am trying to integrate Prometheus into my pipeline but losing steam fast. The Prometheus design seems to desire that you integrate your own cache inside your application and then allow the server to scrape the data, however, if the interval between scrapes is shorter than the longest transient session of your application then you need a gateway. A place to shuttle your data that will be a little more persistent.

(1) storing the data in my application might get me started more quickly
(2) getting the server to pull the data might be more secure
(3) using a push g…