Re: [Radiant] Re: Why is Radiant a self-contained Gem?
On 28/02/09 03:43, somebody called Sean Cribbs (seancri...@gmail.com) wrote this: > 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 [snip] Hi Sean, Appreciate the response - I don't really have anything more to add at this point, except that the rationales given make sense to me ATM. I think I'll need a little more time with Radiant before I can make any solid assessments about whether I truly agree with them in the long term, but for now...I'm on board. Thanks all for making the new guy feel welcome :-) Cheers, Mark __ Mark Glossop - lists cueballcentral com ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Re: Why is Radiant a self-contained Gem?
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: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Re: Why is Radiant a self-contained Gem?
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: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Re: Why is Radiant a self-contained Gem?
Mark Glossop wrote: It does - thanks very much for your clear comments, and also for Jim's questions. The "application" vs. "framework" analogy was particularly useful. Thanks for taking the time. 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." Again - an opinion - which by definition can't always be (rationally) justified. I can't say I agree with everything that Mohit has stated - although I'll readily concede 2a and 2b! - but I understand a little better now. Again - thanks. Glad to help. Happy to engage further in discussion :) Cheers, Mohit. 2/27/2009 | 6:21 PM. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Re: Why is Radiant a self-contained Gem?
On 27/02/09 13:02, somebody called Mohit Sindhwani (t...@onghu.com) wrote this: [snip] >>> >>> Sorry to nag, but - anyone? Bueller? >>> >>> In case this was somehow regarded as trollbait, I'm asking this as a >>> legitimate query...it really is quite important for me to know, and >>> time is >>> a factor for me ATM. >>> >>> To summarise the above verbiage: >>> >>> Why is Radiant delivered with all dependencies included? >> >> Why not? >> Including the dependencies means the instructions for getting started >> for new users will be much simpler. > Actually, I have found this quite useful since you don't always have > access to installing extra gems (or your host is already on different > versions, etc.) - just like you can freeze rails to a specific version > in your specific application, this provides you the ability to create a > "Radiant app" (similar to a Rails app) with the correct versions of > everything (except Ruby) already included. > > As long as you have a compliant Ruby version on your server, you can use > it straight away. > > That said, I think you are asking 2 questions without clearly saying it: > 1. Why is Radiant provided with all its dependencies? > I think the answer is that it reduces dependencies on external code and > different versions of things. Radiant itself uses a number of plugins > and gems (incl Rails) for its work. Out of box, you are assured that > what is provided is tested to work. > > Imagine if you had Textile 4 on the server and Radiant was tested only > with Textile 3.2 and for some reason, there was a conflict that > prevented it from working properly. Here, you know it will work because > it relies on a pre-bundled version. Or in another case, you may have > that Radiant is built with Textile 4 and your server only has Textile > 3.2 - so, Radiant fails! > > In that case, you'd end up with a situation where the installation > instructions go something like: > * Install Textile 4.0 (there are known issues with 3.2 which we will not > fix because we are on a newer version) > * Install acts_as_list (version xx.y) > * Install acts_as_authenticated (version xx.y) > ...and so on! > > You *must* see Radiant as a domain-specific Rails application (though > you can even see it as a domain-specific Ruby application that relies on > a gem called Rails) that provides everything that you need to run it. > > I hope that this clarifies this point. > > 2. I think your second question is more along the lines of why don't I > just get a Rails app, rather than a Rails app that looks like a gem? > This ties in with your comment about not being able to contribute > effectively to the code, etc. I get the feeling that you would prefer a > system where when you run "radiant my_site", you would get the standard > Rails directories, including app, app>view, app>controllers, etc. > > I think some of the Radiant core team can answer this better than me, > but I'll tell you what I *feel* about this structure. > a) It makes some things more difficult for the average Rails programmer > b) It makes many things much simpler for the average CMS developer > c) If Radiant works, my life is much simpler - I don't need to worry or > look at how Radiant is built to be able to use it effectively. > > Since you started by pointing to Redmine, my answer would be: Redmine is > a Rails application for project tracking, etc. It is not a "framework" > for building project tracking applications. IMHO, Radiant is a > framework for building CMS sites. Therefore, the base stuff is kept out > of your way while you can go ahead and build the other things you need - > content, markup, extensions and plugins. You don't use "radiant", you > use a site built using Radiant. > > In some ways, I could say that asking why Radiant is a gem with > dependencies is like asking: why is Rails a gem? Why isn't Rails just > distributed as a set of libraries that someone has to put together by > themselves. I don't know Rails internals, but the question is akin to > asking if all the internal parts of Rails should have been distributed > completely separately. > > Hope this helps. > > Cheers, > Mohit. > 2/27/2009 | 12:02 PM. It does - thanks very much for your clear comments, and also for Jim's questions. The "application" vs. "framework" analogy was particularly useful. Thanks for taking the time. 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." Again - an opinion - which by definition can't always be (rationally) justified. I can't say I agree with everything that Mohit has stated - although I'll readily concede 2a and 2b! - but I understand a little better now. Again - thanks. Cheers, Mark _
Re: [Radiant] Re: Why is Radiant a self-contained Gem?
My apologies that my previous mail went out twice. Mohit. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Re: Why is Radiant a self-contained Gem?
Jim Gay wrote: On Feb 26, 2009, at 10:22 PM, Mark Glossop wrote: On 26/02/09 05:58, somebody called Mark Glossop (li...@cueballcentral.com) wrote this: Evidently that's not enough of a reason for me to _not_ use it, but the question remains: Why is Radiant delivered as a gem with "all the dependencies included"? Or, put another way, why is it not delivered as a Ruby gem with external gem dependencies, that generates a "standard" Rails app structure when invoked? Some clarification (please note, all of the following are IHMO): * Some much larger apps [Redmine comes to mind] don't use this approach and are actually simpler to deploy than Radiant. Really. How so? * Yes, I know "standard" isn't exactly well-defined AFA Rails is concerned. * "gem unpack" is not a valid answer/workaround. Why not? You can also "rake radiant:freeze:gems" or "rake radiant:freeze:edge" Or you could clone the repository and modify it just like any other app. * The closest rationale I have found for this question is in the Radiant FAQ - "Gems: Versions of any required libraries are built-in. So that means that you don't need to have the rails gem installed: the radiant gem comes bundled with a particular version." Right... * It also makes it harder to consider contributing code to Radiant. How so? Apart from my own curiosity, my business partners will want to know why I have chosen Radiant for the CMS I am working on. This info helps me with them. If the full reasoning behind this design decision is already online somewhere, please just point me there, as my Google-fu has obviously not been working. Thanks! Cheers, Mark *bump* Sorry to nag, but - anyone? Bueller? In case this was somehow regarded as trollbait, I'm asking this as a legitimate query...it really is quite important for me to know, and time is a factor for me ATM. To summarise the above verbiage: Why is Radiant delivered with all dependencies included? Why not? Including the dependencies means the instructions for getting started for new users will be much simpler. Actually, I have found this quite useful since you don't always have access to installing extra gems (or your host is already on different versions, etc.) - just like you can freeze rails to a specific version in your specific application, this provides you the ability to create a "Radiant app" (similar to a Rails app) with the correct versions of everything (except Ruby) already included. As long as you have a compliant Ruby version on your server, you can use it straight away. That said, I think you are asking 2 questions without clearly saying it: 1. Why is Radiant provided with all its dependencies? I think the answer is that it reduces dependencies on external code and different versions of things. Radiant itself uses a number of plugins and gems (incl Rails) for its work. Out of box, you are assured that what is provided is tested to work. Imagine if you had Textile 4 on the server and Radiant was tested only with Textile 3.2 and for some reason, there was a conflict that prevented it from working properly. Here, you know it will work because it relies on a pre-bundled version. Or in another case, you may have that Radiant is built with Textile 4 and your server only has Textile 3.2 - so, Radiant fails! In that case, you'd end up with a situation where the installation instructions go something like: * Install Textile 4.0 (there are known issues with 3.2 which we will not fix because we are on a newer version) * Install acts_as_list (version xx.y) * Install acts_as_authenticated (version xx.y) ...and so on! You *must* see Radiant as a domain-specific Rails application (though you can even see it as a domain-specific Ruby application that relies on a gem called Rails) that provides everything that you need to run it. I hope that this clarifies this point. 2. I think your second question is more along the lines of why don't I just get a Rails app, rather than a Rails app that looks like a gem? This ties in with your comment about not being able to contribute effectively to the code, etc. I get the feeling that you would prefer a system where when you run "radiant my_site", you would get the standard Rails directories, including app, app>view, app>controllers, etc. I think some of the Radiant core team can answer this better than me, but I'll tell you what I *feel* about this structure. a) It makes some things more difficult for the average Rails programmer b) It makes many things much simpler for the average CMS developer c) If Radiant works, my life is much simpler - I don't need to worry or look at how Radiant is built to be able to use it effectively. Since you started by pointing to Redmine, my answer would be: Redmine is a Rails application for project tracking, etc. It is not a "framework" for building project tracking applications. IMHO, Radiant is a framework for building CMS sites. Theref
Re: [Radiant] Re: Why is Radiant a self-contained Gem?
Jim Gay wrote: On Feb 26, 2009, at 10:22 PM, Mark Glossop wrote: On 26/02/09 05:58, somebody called Mark Glossop (li...@cueballcentral.com) wrote this: Hi all - first time poster here [didn't want to hijack the thread about Dreamhost, so started a new one...I have a very specific question, related to the OP about Dreamhost.] It's good to be hearing this about Dreamhost now, especially when I'm looking to deploy this weekend. Only started with Radiant about a week ago. Doing my dev work on local box, and have been a little concerned about the sorcery that it may take to get everything moved over onto Dreamhost's "special" environment. I'm deliberately doing all the dev locally since that's how I'm used to doing Rails dev work; no developtestduction here! :-) Anyhow - this whole issue brought something back to me...something that initially made me steer away from Radiant as a CMS when I was looking around at various CMS options. I liked Radiant, but didn't like the way it was packaged up. Evidently that's not enough of a reason for me to _not_ use it, but the question remains: Why is Radiant delivered as a gem with "all the dependencies included"? Or, put another way, why is it not delivered as a Ruby gem with external gem dependencies, that generates a "standard" Rails app structure when invoked? Some clarification (please note, all of the following are IHMO): * Some much larger apps [Redmine comes to mind] don't use this approach and are actually simpler to deploy than Radiant. Really. How so? * Yes, I know "standard" isn't exactly well-defined AFA Rails is concerned. * "gem unpack" is not a valid answer/workaround. Why not? You can also "rake radiant:freeze:gems" or "rake radiant:freeze:edge" Or you could clone the repository and modify it just like any other app. * The closest rationale I have found for this question is in the Radiant FAQ - "Gems: Versions of any required libraries are built-in. So that means that you don't need to have the rails gem installed: the radiant gem comes bundled with a particular version." Right... * It also makes it harder to consider contributing code to Radiant. How so? Apart from my own curiosity, my business partners will want to know why I have chosen Radiant for the CMS I am working on. This info helps me with them. If the full reasoning behind this design decision is already online somewhere, please just point me there, as my Google-fu has obviously not been working. Thanks! Cheers, Mark *bump* Sorry to nag, but - anyone? Bueller? In case this was somehow regarded as trollbait, I'm asking this as a legitimate query...it really is quite important for me to know, and time is a factor for me ATM. To summarise the above verbiage: Why is Radiant delivered with all dependencies included? Why not? Including the dependencies means the instructions for getting started for new users will be much simpler. Actually, I have found this quite useful since you don't always have access to installing extra gems (or your host is already on different versions, etc.) - just like you can freeze rails to a specific version in your specific application, this provides you the ability to create a "Radiant app" (similar to a Rails app) with the correct versions of everything (except Ruby) already included. As long as you have a compliant Ruby version on your server, you can use it straight away. That said, I think you are asking 2 questions without clearly saying it: 1. Why is Radiant provided with all its dependencies? I think the answer is that it reduces dependencies on external code and different versions of things. Radiant itself uses a number of plugins and gems (incl Rails) for its work. Out of box, you are assured that what is provided is tested to work. Imagine if you had Textile 4 on the server and Radiant was tested only with Textile 3.2 and for some reason, there was a conflict that prevented it from working properly. Here, you know it will work because it relies on a pre-bundled version. Or in another case, you may have that Radiant is built with Textile 4 and your server only has Textile 3.2 - so, Radiant fails! In that case, you'd end up with a situation where the installation instructions go something like: * Install Textile 4.0 (there are known issues with 3.2 which we will not fix because we are on a newer version) * Install acts_as_list (version xx.y) * Install acts_as_authenticated (version xx.y) ...and so on! You *must* see Radiant as a domain-specific Rails application (though you can even see it as a domain-specific Ruby application that relies on a gem called Rails) that provides everything that you need to run it. I hope that this clarifies this point. 2. I think your second question is more along the lines of why don't I just get a Rails app, rather than a Rails app that looks like a gem? This ties in with your comment about not being able to contribute effecti
Re: [Radiant] Re: Why is Radiant a self-contained Gem?
On Feb 26, 2009, at 10:22 PM, Mark Glossop wrote: On 26/02/09 05:58, somebody called Mark Glossop (li...@cueballcentral.com ) wrote this: Hi all - first time poster here [didn't want to hijack the thread about Dreamhost, so started a new one...I have a very specific question, related to the OP about Dreamhost.] It's good to be hearing this about Dreamhost now, especially when I'm looking to deploy this weekend. Only started with Radiant about a week ago. Doing my dev work on local box, and have been a little concerned about the sorcery that it may take to get everything moved over onto Dreamhost's "special" environment. I'm deliberately doing all the dev locally since that's how I'm used to doing Rails dev work; no developtestduction here! :-) Anyhow - this whole issue brought something back to me...something that initially made me steer away from Radiant as a CMS when I was looking around at various CMS options. I liked Radiant, but didn't like the way it was packaged up. Evidently that's not enough of a reason for me to _not_ use it, but the question remains: Why is Radiant delivered as a gem with "all the dependencies included"? Or, put another way, why is it not delivered as a Ruby gem with external gem dependencies, that generates a "standard" Rails app structure when invoked? Some clarification (please note, all of the following are IHMO): * Some much larger apps [Redmine comes to mind] don't use this approach and are actually simpler to deploy than Radiant. Really. How so? * Yes, I know "standard" isn't exactly well-defined AFA Rails is concerned. * "gem unpack" is not a valid answer/workaround. Why not? You can also "rake radiant:freeze:gems" or "rake radiant:freeze:edge" Or you could clone the repository and modify it just like any other app. * The closest rationale I have found for this question is in the Radiant FAQ - "Gems: Versions of any required libraries are built-in. So that means that you don't need to have the rails gem installed: the radiant gem comes bundled with a particular version." Right... * It also makes it harder to consider contributing code to Radiant. How so? Apart from my own curiosity, my business partners will want to know why I have chosen Radiant for the CMS I am working on. This info helps me with them. If the full reasoning behind this design decision is already online somewhere, please just point me there, as my Google-fu has obviously not been working. Thanks! Cheers, Mark *bump* Sorry to nag, but - anyone? Bueller? In case this was somehow regarded as trollbait, I'm asking this as a legitimate query...it really is quite important for me to know, and time is a factor for me ATM. To summarise the above verbiage: Why is Radiant delivered with all dependencies included? Why not? Including the dependencies means the instructions for getting started for new users will be much simpler. You listed several comments that suggest it is harder to deploy/ contribute/develop with Radiant, but provided no information about why that is your opinion. How would you want Radiant to be structured and why? -Jim TIA for any and all responses. If you'd prefer to respond off-list, please feel free. Regards, Mark __ Mark Glossop - lists cueballcentral com ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
