Encoding of strings coming out of SQLite (Bug #511)

Thanks for your investigations.

I'm not sure, why we stick to sqlite3 < 1.3. I think it is related to 1.8.6 support. But since, we are no longer support 1.8.6 with ChiliProject 2.0, it might very well be, that the reasons to do so, have vanished.

So I see 2 options here.

1. Your proposed solution to use a newer version on Ruby 1.9

2. Remove the limitation and make it work for all Rubies.

Actually I would prefer the second, but I currently do not have the time to run the tests on at least 1.8.7 and 1.9.2 with sqlite3 1.3.3. Also it would be great, if it would not totally break on JRuby 1.6.x

If there are reasons, why we need to go with option 1, I would prefer, if you used the platform mechanism of bundler-. This way, bundler will be aware of platform differences and can resolve dependency cross-platform, but install only for the local one.

Would you have the time to test option 2 ?

Cited from https://github.com/finnlabs/chiliproject-gemfile which served as the basis for ChiliProject's current Gemfile:

Target operating system is currently Debian Stable [i.e. Lenny --Holger]. This may result in the need
to use older versions of some gems, than technically possible. This is most
notably the following gems

• sqlite3-ruby must be older than 1.3
• rmagick must be older than 2.0

I'll quickly prepare a pull request, that updates rmagick and adds special handling for sqlite in 1.9.

Ok. I'm giving up. It is not possible to express the things, Eric laid out using bundler's API.

Something like the following is not possible.

gem "sqlite3", :platform => :ruby_19
gem "sqlite3-ruby", "< 1.3", :require => "sqlite3", :exclude_platform => :ruby_19

This way, bundler would be able to properly resolve versions for all dependencies. But as I said, it is not possible to express things that way. The only option would be to use the initial approach, proposed by Gary Verhaegen. On the other hand, this is generally not desirable. See the bundler FAQ for a discussion - there it is explained for groups, but the same goes for platforms. Whenever we are hiding dependencies with conditionals, we are running into new kinds of problems.

I was able to install sqlite3 1.3 properly on Debian Squeeze (with RVM), so technically, there seems to be no reason to stick to 1.3. The only one would be, that the system's gem (installed via apt-get) would satisfy the requirement and bundler would not try to install a newer version. This might save you from installing build tools on your app server.

So to put it another way: I'm not able to fulfill Eric's request, without hurting bundler's basic way of doing things. I, personally, would not face any disadvantages from updating to sqlite3 1.3, since I am generally avoiding the package maintainers versions of ruby and gems anyway, and the gem seems to build fine on Debian Stable.

Again. I'm giving up on this issue. I'll let smarter people - having more experience in installation and dependency management - decide.

I'm not sure where I already said that, but I'd be in favor of having a more generic Gemfile and add the necessary changes for distro-specific changes in the tutorials and/or as comments.

Couldn't we do this?

1gem "sqlite3", :platforms => :mri_19
2gem "sqlite3-ruby", "< 1.3", :require => "sqlite3", :platforms => :mri_18

This is how I'm loading ruby-debug for 1.8 vs 1.9 locally. (I don't know if there is a difference between mri_18 and ruby_18)

If not, what would be the simplest thing that could work? Have our Gemfile require Debian testing and add docs for changing it for Debain stable?

Gnahh. I totally missed the surrounding platforms :mri block. In that case, would can be pretty sure, that we've only got mri_18 and mri_19. So your code block should actually work.

Now I'm realizing, that we've got not database adapters for rubinius defined. I should shed a light on that in the future.

Whoever is committing this should leave a comment or link to this issue, so that we are able to find out, why we are using an older sqlite3 on Ruby 1.8.