Vendor/rails and vendor/plugins vs. system wide rails

Hi:

I am at the end of my development cycle. I am just wondering if others
could give me some deployment advice.

it is nice to have rails system wide thats how i have it on my Mac…
however I have some plugin system wide and some under vendor/plugins…
it just happen that way …Now it is nice to package everything that you
need under vendor i.e. rails 1.2.2 plus all the plugin application
needs. My question is are there any downside … i.e performance, maint.
etc… that i need to think about. Is there any rails best practice?

I appreciate your response.

I’m not sure there’s any best practice. But I highly recommend to freeze
rails (and any other gems you use) in vendor/.

Firstly, your app works with these versions correctly. Can you guarantee
that if a sysadmin decides to upgrade some gems (or downgrade one for
another app?) that your application still works as expected.

Some time back a lot of people on shared hosting hosted their Typo blogs
with a system-wide Rails gem. The admin decided to upgrade rails, and
all Typo blogs broke. You probably don’t want that happening.

Secondly, if you want to upgrade to a new verson of a gem or maybe even
Rails, you can test this in development first before deploying.

Thirdly, if there are multiple developers on your project, how do you
know you all use the same gems?

I think freezing all that stuff is just great to do. As far as I know
there are no performance downsides to this.

Ariejan De vroom wrote:

I’m not sure there’s any best practice. But I highly recommend to freeze
rails (and any other gems you use) in vendor/.

Firstly, your app works with these versions correctly. Can you guarantee
that if a sysadmin decides to upgrade some gems (or downgrade one for
another app?) that your application still works as expected.

Some time back a lot of people on shared hosting hosted their Typo blogs
with a system-wide Rails gem. The admin decided to upgrade rails, and
all Typo blogs broke. You probably don’t want that happening.

Secondly, if you want to upgrade to a new verson of a gem or maybe even
Rails, you can test this in development first before deploying.

Thirdly, if there are multiple developers on your project, how do you
know you all use the same gems?

I think freezing all that stuff is just great to do. As far as I know
there are no performance downsides to this.

Thank you. Thats what I thought. Cool!

Cheers

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs