My apologies for not responding to this thread sooner. Mohit and Jim
already touched on reasons why Radiant is kind of an all-in-one package
but I want to reiterate and clarify some of those.
* Reduces compatibility issues - libraries will work as intended.
* Assists with shared-hosting scenarios - who knows what libraries will
be installed, and whether you'll have ability to update them.
* Allows the core-team to apply patches to included libraries as
necessary. (This was a bigger problem around Rails 1.2 time)
* Allows us to include a non-release version of a library as necessary.
* Allows you to package up an entire Radiant project, including a frozen
version of Radiant in vendor/radiant, and mostly guarantee it will work
wherever you deploy it.
* RubyGems is nice, but not perfect. We'd rather not place our project
at the mercy of an old or broken version.
Now, there are a number of dependencies we do not include:
* DB Drivers - mysql, postgres, sqlite3 - these generally have native
components that we cannot guarantee will compile.
* RSpec and RSpec-Rails - at the request of a number of devs, these were
removed from the project so that various tools (autotest, TextMate)
would play nicer, especially during extension development. However,
they are specified as gem dependencies and should be installed along
with Radiant.
There are two libraries that are pre-packaged but will use system gems
if present:
RedCloth: We package version 3.0.4, but it will load RedCloth 4.x if the
gem is present.
BlueCloth: We package version 1.0.x, but it will load RDiscount if the
gem is present. (Only related to Markdown Filter)
You are not the first to question why we do things this way, and I
reconsider it about every 6 months. However, I believe the benefits of
packaging dependencies -- primarily "it just works" -- outweigh the costs.
Cheers,
Sean
Mohit Sindhwani wrote:
Mark Glossop wrote:
Jim, I haven't answered your questions since Mohit's answer clarifies
a lot
for me, and much of my opinions were/are based on little more than
gut feel
and a lot of IT experience. Were I to give any answers, they likely
wouldn't
say more than "I'd like it to be less surprising to someone who has
experience with Rails development."
Just going back to this a bit, Mark - are you saying that the reason
it would be better to distribute Radiant as a "rails app" because it
would be less surprising to someone who has experience with Rails
development? I like to think of Radiant as a Ruby application that
relies on Rails (rather than a Rails app). I see that as a plus, and
its reliance on Rails means that someone can write an extension for it
using what they learnt when they did Rails.
Anyway, it's good that you're feeling clearer about it - someone in
core may be able to answer some of your other questions :)
Cheers,
Mohit.
2/27/2009 | 11:46 PM.
_______________________________________________
Radiant mailing list
Post: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
_______________________________________________
Radiant mailing list
Post: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
