RubyGems 1.8.6

drbrain | Tue, 26 Jul 2011 00:55:49 GMT

rubygems-update version 1.8.6 has been released!

RubyGems is a package management framework for Ruby.

This gem is an update for the RubyGems software. You must have an installation of RubyGems before this update can be applied.

See Gem for information on RubyGems (or `ri Gem`)

To upgrade to the latest RubyGems, run:

$ gem update --system  # you might need to be an administrator or root

See UPGRADING.rdoc for more details and alternative instructions.


If you don’t have RubyGems installed, your can still do it manually:

  • Download from: rubygems.org/pages/download

  • Unpack into a directory and cd there

  • Install with: ruby setup.rb # you may need admin/root privilege

For more details and other options, see:

ruby setup.rb --help

Changes:

1.8.6 / 2011-07-25

  • Major enhancements:

    • Restore behavior of Gem::Specification#loaded? Ruby Bug #5032

  • Minor enhancements:

    • Add autorequires and delay startup of RubyGems until require is called. See Ruby bug #4962

  • Bug fixes:

    • Clean up SourceIndex.add_specs to not be so damn noisy. (tadman)

    • Added missing APPLE_GEM_HOME in paths.

    • Extend YAML::Syck::DefaultKey fixing to `marshal_dump` as well.

    • Fix #29216: check correct bin_dir in check_that_user_bin_dir_is_in_path.

    • Revert Gem.latest_load_paths to working order (PathSupport revert).

    • Restore normalization of GEM_HOME.

    • Handle the Syck DefaultKey problem once and for all.

    • Fix SystemStackError occurring with “gem list -r -a” on 1.9.

Posted in ,  | no comments | 1 trackback

Proposal: Net::HTTP user-agent class for Ruby stdlib

drbrain | Mon, 25 Jul 2011 19:36:58 GMT

I have proposed adding a new class to Ruby's standard library that makes Net::HTTP easier to use. You can read my HTTP user-agent class proposal on redmine.

The first question is not "What should the API look like?" but "Should it be in the standard library?". My argument is this:

I have had discussions where people say "Net::HTTP's API is not very good" and people seem to want a better way to use Net::HTTP without trying out one of the many Net::HTTP::Agent-like extensions to the base API.

Having a recommended way to perform HTTP access in ruby will be useful to the community since they don't have to do any additional research. Also users will be able perform basic HTTP requests for multiple servers and will gain the efficiencies of persistent connections without extra work.

The biggest issue people have is that they need to pass the host, port and SSL params for every HTTP connection made. The nature of the API means that most people make a new connection for every request. Since this is confusing for new users and annoying for experienced users I think it should be addressed in stdlib.

Do you think a smoother API for performing HTTP requests would be useful in Ruby's standard library? If you do (or don't) I'd appreciate further discussion on the ticket.

Posted in  | 5 comments | no trackbacks

Why are you updating your VERSION twice?

drbrain | Sun, 10 Jul 2011 01:10:00 GMT

I was looking at a project on GitHub and noticed two commits, one after the other, each updating the version of the project in different files.

Then I looked through GitHub's popular forked repositories list and picked out the first several ruby projects and poked through them to see how many made multiple commits to update the version.

While my sample size was only seven or eight ruby libraries, only one updated the version in one place. (Looking through other gems in the past has shown me that most gem maintainers update their versions in multiple files, so pointing out the guilty would be pointless.)

I'm continually puzzled that Ruby projects don't apply the DRY principle to what I have found to be the most error-prone portion of being a library maintainer, releasing the library correctly.

Since Ryan and I put Hoe together there have been several other projects that claim various benefits over Hoe, but I haven't seen a single one that has the "single, unambiguous, authoritative representation" for such a basic piece of information as the version.

Looking through the commit messages of the popular project, one project was released with differing versions between the gemspec and the VERSION constant. Why use a release tool (or process) that allows this to happen? Hoe doesn't! It checks to make sure the VERSION you release matches up with the VERSION in your source (the single, unambiguous authoritative representation) so you can't do that!

Please, please, look at the tools you use to manage your project. Do they make you do extra work like editing the same data twice? Do they prevent you from shooting yourself in the foot?

If they don't make your life easier then fix them or ditch them. While I know that Hoe is the best tool available for developing, maintaining and releasing gems, I know that not everyone seems to agree (even though they're wrong ☺). If you don't like Hoe or don't want to switch to Hoe the least you could do is fix the tool you use to help you instead of hinder you.

Posted in  | 5 comments | no trackbacks