|« Protip: Enable !$||Quick & easy ROT13 for the command line »|
Tue, Apr 02, 2013
So, last week I took my first steps into putting stuff onto CPAN, and was impressed at how easy Dist::Zilla made things.
Given that Miyagawa's attempt to make CPAN better was cpanminus; and his attempt to make web frameworks better was Plack; I generally find it's worthwhile to take a look at stuff he creates to make things better :)
So, I watched the screencast and it all seemed very nice & shiny. I wanted to have a go. But it'd be easier to do it with something I was starting from scratch.
I needed to make a new package!
Actually, not such a difficult problem - I have a bunch of scripts I use all the time that could stand being properly packaged & released. So I picked the one that would benefit the most, a script called 'g2'
cpanm installed Milla to my server, and Milla set up my directory with not just Perl and CPAN boilerplate, but git stuff too.
I then wrote a quick & simple version of the script, with the bulk of the logic shunted out to an object I hadn't written yet. This was the first big change I'd wanted to make to the script I already had, which was just one big piece of Perl. The other was to make it use config files rather than hard-coding the servers & commands it could handle, which was done simply via Config::Tiny.
With the script duly written, I went to write the object that would handle all the real logic. Since this object was for use by a fire-once script rather than a persistent service, I wanted to avoid Moose to keep it quick, so I fell back on Moo. Which I'm developing a real fondness for.
In surprisingly little time, the object was written, as were some basic tests. The simple functionality was done & dusted. Now I just had to add the little tweaks that would make it nicer to use. This involved making some tweaks to how it parsed commands, and some slightly horrible logic to munge the /etc and ~/ config file contents together. I imagine there's a better way to do it, but I haven't had time to find it yet.
Eventually, it all looked good, and I told Milla to release to CPAN.
It hit an error. A test file it had generated for me was failing.
Damn. And it had been going so well, too.
I had a quick poke around but didn't see any obvious way to work around the problem. I went to file a bug report. And there, joy of joy, was an existing ticket for the very bug I was having an issue with. And in it was the workaround. I applied it, and bang! Module uploaded to CPAN!
And also to Github, with the auto-generated makefile & everything. It's very helpful, having your inline POD get turned into the application's man page and the github README.md without having to lift so much as a finger. And having the version numbers get bumped for you automatically.
So yes, Milla was quite impressive, and is certainly what I'll be using for the time being. Thanks, Miyagawa!
A day or two later, I got an email come through about my module. CPAN testers had found problems.
For those of you who don't know, every module that gets uploaded to CPAN gets tested by a bunch of volunteers, which means your module gets tested on all architectures and versions imaginable. It's a really helpful service, making it possible to get cross-platform compatible code with a minimum of difficulty. In my case, it had found that I hadn't declared Moo as a required module. I added 'AutoPrereqs' to my dist.ini, and generated a new release. Moo was now found & declared correctly. Sweet!
This morning's email from the testers still reveals a few issues, but they're with Perl 5.17, so I'm not convinced it's my module that's at fault :)
In the meantime, the application should work just fine for most people. It's something I find invaluable at work, where we have many servers we often need to ssh to and many directories we frequently need to access.
It allows you to replace commands like:
ssh long-server-name cd /annoying/long/file/path
With something more like:
g2 lng path
It also allows for some dynamic generation/modification of configured commands, so
g2 lng path/sub/dir
is equivalent to
ssh long-server-name cd /annoying/long/file/path/sub/dir
And situations like
ssh client1 cd /annoying/long/file/path/for/client1 ssh client2 cd /annoying/long/file/path/for/client2
can be handled by a single command that includes a reference to the hostname in the command output.
I'm toying with the idea of adding bash tab-completion, and I'd really like to improve the config-munging logic. So it's by no means finished yet. But if you ssh around a lot to servers with names longer than they need to be, you may find this helps: All it needs is the shortest unambiguous string to identify a server; and an optional command to run when it gets there.
|<< <||> >>|