11:00 am, 21 Jan 07
releasing ruby software sucks
I like releasing the software I write because other people sometimes find it useful, but the overhead of going through the release process is killing me. I have a simple (single-file) Ruby module, but actually publishing it entails installing Rake (a gratuitous rewrite of make in Ruby) so I can create a Ruby gem (an annoying packaging format I've grumbled about before) and then I have to go through agonizing RubyForge (sourceforge, but somehow even worse?) and its endless web forms to actually publish my stuff. (And don't even get me started on how annoying rdoc is...)
Now, it surely isn't as bad as I've just made it out to be -- surely people have automated this? But as far as I can tell that process is not documented anywhere, and every popular Ruby project I've checked has its own complicated Rakefile that requires even more software installs to make this stuff work.
It occurs to me now that the simpler approach is to just tell users "download this file and stick it in your directory if you wanna use it". But that isn't sufficient for more complicated, multi-file stuff like ljrb.
Mysteriously, the only programming language that seems to have solved this well is C: if I need a C library I apt-get it, and everything else uses autoconf so the build flags are the same between projects. Don't get me wrong -- autoconf is certainly agonizing but is a single point of pain. (I wish gtk-doc wasn't such a pain to use, too.)
Now, it surely isn't as bad as I've just made it out to be -- surely people have automated this? But as far as I can tell that process is not documented anywhere, and every popular Ruby project I've checked has its own complicated Rakefile that requires even more software installs to make this stuff work.
It occurs to me now that the simpler approach is to just tell users "download this file and stick it in your directory if you wanna use it". But that isn't sufficient for more complicated, multi-file stuff like ljrb.
Mysteriously, the only programming language that seems to have solved this well is C: if I need a C library I apt-get it, and everything else uses autoconf so the build flags are the same between projects. Don't get me wrong -- autoconf is certainly agonizing but is a single point of pain. (I wish gtk-doc wasn't such a pain to use, too.)
not anymore
Releasing ruby software USED to suck... Use hoe. then: enjoyRe: not anymore
Neat idea!Two comments.
1) Bug report:
puppy:~/projects/rubypuz% sow rubypuz
/usr/bin/env: ruby -ws: No such file or directory
% which sow
/usr/bin/X11/sow
The first line is "#!/usr/bin/env ruby -ws", which apparently doesn't quite parse.
2) Is there any reason you chose a different file naming convention? Typically Unix stuff uses "README", not "README.txt". It appears the latter is hard-coded into the "docs" task.
Re: not anymore
I'm aware of the env thing on linux... it sucks. I doubt I can/will do anything about it. But ultimately it is a rubygems issue since that is a generated script wrapper made by rubygems. I personally hardcode all my paths instead of using env for exactly that reason.The naming conventions... I just like it better that way.
Re: not anymore
I'm told by Eric that rubygems 0.9.1 uses /usr/bin/env if you set a flag -E on gem install, but otherwise defaults to off. Update rubygems and then "sudo gem pristine --all" should fix those.Sure, it has its share of suck: you can't easily uninstall packages and putting up different versions of the same module is hairy. But in debian you can at least also
(And yes, this means that the ECMAScript 4 development effort is terribly irresponsible. I pacify my feelings of guilt by telling myself that we're breaking lots of new ground in the type system, and that the number of conflicting historical constraints on loading, naming, security and embedding environments for ES3 makes a broadly-applicable distribution system very hard to describe. I still wish we'd managed to nail down a meaningful form of content-addressed module naming, but alas.)
Sorry... but that is just utter tripe, even after overlooking the complete hypocrisy wrt EMCAScript. Languages are designed and written because of an idea of how to express something. Packaging, distribution, and versioning are rarely, if ever, the target of those ideas and as a result, are tangents from the goal. To accuse someone (or something) irresponsible for avoiding (or ignoring or delaying) those tangents is a red herring.
(And if I had my way wrt. ECMAScript, we'd have spent 10% as much time on the type system and the rest on a better standard library and packaging/distribution/versioning system. I made proposals, but they were sketches and it's a big topic that takes focus and work. We spent our time elsewhere. It's a committee, so I don't get to dictate where we focus.)
Dude, Ruby's over a decade old
http://en.wikipedia.org/wiki/Ruby_%28programming_language%29"The language was created by Yukihiro "Matz" Matsumoto, who started working on Ruby on February 24, 1993, and released it to the public in 1995."
Re: Dude, Ruby's over a decade old
Ok. They couldn't have seen it coming. Newer languages ought to be able to, though.