2011/5/23 Ilias L. [email protected]:
Also, if you want this attempt to be solved in each of the libraries
you mention, patches are welcome.
I understand that “patches are welcome”, as those are open source
Actually, “open source” projects and “patches are welcome” projects
aren’t the same thing at all, though the two groups have considerable
overlap. Its quite possible for something to be released under an open
source license but not be particularly welcoming of community patches.
The “thin” / “eventmachine” issue is trivial:
- thin should require only “eventmachine” versions which have native
Which eventmachine versions (if any) have pre-compiled native gems
available will depend on which platform you are using Ruby on, though
AFAIK is mostly an issue on Windows platforms, which are the main
platforms where a Ruby developer (using the main, C-based
implementation) may not have a usable environment to build native
extensions. But I don’t think that gem developers should avoid relying
on C-based extensions that don’t have pre-built Windows binaries
available just to suit Windows users anymore than they should avoid
relying (or creating) C-based extensions entirely just to suit users
of other Ruby implementations (e.g., JRuby, MagLev, whatever) that
don’t support C-based extensions in the first place.
At any rate, the place to address this issue is by filing a bug report
on the thin projects issue tracker.
The “json” issue:
- should provide native gems, or
- should provide “json_pure” as a pseudo-native-gem for windows (or
as a general fallback)
Generally, as above, except for which project’s issue tracker this
should be filed with if you want it changed.
The “gem” issue:
The gem team should provide a mechanism for “fallbacks”, in order to
ensure that cases like “json” can be resolved immediately without user
interventions (instead of aborting the gem installation sequence which
is triggered by a gem with dependencies).
I actually agree that or-based (rather than only and-based)
dependencies for gems is a really good idea.
Again, the place for this is, first-and-foremost, the RubyGems project.
Some gems are far to important, and they can mess up the user-
Developers ought to be able to read the docs of gems they might depend
on and figure out if they are right for their work (including
consideration of the platform on which they are working and the
availability of build tools; or, where appropriate, considering which
platform is appropriate given what they want to be building.)
Users that are not developers ought to be insulated from this issue by
application developers consideration toward end users, including
things like delivering prepackaged apps that include all dependencies,
for which end there are a variety of tools (e.g., Bundler) available
in the Ruby ecosystem.