What's wrong with using a framework that has a lot of dependencies? [closed]

Question

I recently told a friend that I was starting to learn Catalyst (Perl) and he fairly strongly emphasized that because Catalyst has so freakin' many dependencies, I should use something like Rails instead.

Isn't that a good thing that there are a lot of dependencies? Doesn't that indicate a lot of code re-use? I understand that there might be more effort involved with installing the framework but are there any other disadvantages?

I will resume my Catalyst tutorial until I get some juicy responses. :-)

Mucus

I'm sure this isn't keeping anyone up at night but it was tough picking an answer for this question. Thanks for all of them! I decided to stick with my Catalyst tutorial on CPAN and I ordered both Catalyst books (from betterworldbooks.com). Thanks for the confidence boost, Mr. Rockway! – Mucus

Answer 1

When there are version dependencies between components, you can find yourself backed into a non-working situation if you're forced to upgrade one component (say, for security reasons) before a compatible version of a dependent component is available.

That assumes you can get into a working state in the first place. It may be that if you try to use the current versions of all dependencies, you'll find that they don't play along.

The larger the number of dependencies, the greater the risk.

Rails isn't free of this problem, either. With every new Ruby release, there's a scramble to update instructions for how to get, say, database drivers built.

To be fair, this problem has trended towards "better" over time, albeit with bumps in the road.

Markos

Rails' problem isn't really with the number of dependencies — besides its constituent frameworks, it only depends on Rake. – Cochard

Theoretically true, but not for Catalyst. Most of Catalyst's cdependencies were written specifically for Catalyst, and are maintained by the same group that maintains Catalyst::Runtime. If something goes wrong with a dependency and that breaks some other dependency, we would release everything at the same time. This has never happened, however. – Humperdinck

@Chuck, if you read his post, you'd notice that he was talking about things like database drivers. Sure, Rails probably doesn't depend on a database driver, but I bet your app does. – Humperdinck

You can use Rails without a database (and hence a database driver), but that's the 2% case. Ditto with Django. – Markos

Another thing to note is that Perl module versions are typically very backward compatible - so Catalyst doesn't depend on Some::Module version 3, but Some::Module version >=3. On the other hand, this means that while Catalyst installs with many module combinations, there's no guarantee your combination has previously been tried. On the other other hand, Catalyst and all its dependent Perl modules come with a bucketload of tests that automatically run when you install. – Stu

This shouldn't be marked as the best answer, as it's another example of an opinion from a Ruby/Rails person who doesn't understand the high level capabilities of Perl/CPAN and how they relate to Catalyst. – Bareilly

Answer 2

There is nothing particularly wrong with this. The advantage of Catalyst is that its pieces can be used by people not using all of Catalyst. This means that there are more eyes looking at, and fixing bugs in, the critical parts.

The biggest complain I hear of is that it's annoying to watch all those messages go by in the CPAN shell as Catalyst is installing. The solution is to take advantage of your OS's package manager as you are getting started. On Debian, apt-get install libcatalyst-perl takes 15 seconds to install on a machine with no other Perl modules installed. 15 seconds. (A plain CPAN install is not difficult either, but I guess the standard CPAN shell asks you a lot of dumb questions, and that puts off the newbies.)

Don't worry about the dependencies, there are good tools for managing them, and they make the framework stronger and more flexible.

Humperdinck

Answer 3

This is a subject I've seen postings about before. I've been meaning to write an article about it and have finally done so.

It is here: The Lie of Independence

I encourage you to read it. The gist is simple, though. The question is wrong. It's not 'Do you use an application or framework with lots of dependencies, or one that doesn't have them?'

It is: 'Do you use an application or framework that has lots of external dependencies, or one that tries to do it all internally?'

And the question that follows is 'Do you really have faith that the person or people writing this framework understand every nuance of every tiny detail of every task that needs to be done to process a web request?'

Schenck

Very helpful article! Thanks, jayk. – Mucus

Answer 4

My personal experience is that the more dependencies you have, the more versioning you have to keep track of, and this can lead to nightmarish situations. In particular, updating one dependency (due to a bug you want fixed, for example) can bring you compatibility issues with the other dependencies. As an example, I personally had a situation where gcc 4.0.3 worked with foo but not with bar (dependency of foo), and gcc 4.0.5 worked with bar but not with foo. Fortunately, 4.0.2 worked.

Also, more dependencies tend to point out at "Frankenstein's monsters" products, made of parts that were not designed upfront to play together. A well integrated framework is designed to play nice and consistent. This, of course, can be fixed by proper wrapping the differences.

Humus

All the parts of Catalyst are designed to integrate with each other. They are also designed to be usable on their own. – Humperdinck

Perl's module tests make this scenario a lot less likely and, in the cases it happens, a lot easier to report as a bug. – Stu

@jrockway: Design goals and reality are often separate things. – Breastfeed