Wednesday, July 29, 2009

On dependencies

Ovid writes about Mojolicious::Lite:

The fact that it has no dependencies makes it even more compelling.It's the sort of thing one could more easily attract new developers with. Can you imagine rewriting my old CGI course with something like this? Or maybe a way to introduce new users to Perl? There are many excellent Perl frameworks out there which I would, nonetheless, hesitate to start new users on. Just trying to set up CPAN can be difficult for them; working through even one test failure is often too much. For people who want to jump in and learn "Web programming", though, this might work.

On the other hand Jay advices to stop worrying about dependencies The lie of independence - or - how I learned to stop worrying and love the dependency chain. There is truth in both statements. I have the impression that the problem of CPAN dependencies have improved much recently. The visibility of installation problems directly from the cpan search engine (cpan testers matrix, dependencies review) is a great step ahead. But still installing Catalyst and DBIC and TT is a big hurdle - and I can understand why Ovid is not enthusiastic about teaching Perl novices how to do that.

For me Mojo sounds like iPod - slick and beautiful and really useful - but you are not supposed to change the battery. It is a nicely integrated product - but somehow closed. The author apparently tries to make it perfect, tries to polish every detail - what perhaps would not be possible if he had to compromise with the visions of the authors of the other packages. I can feel his frustration here. But rejecting all dependencies and rewriting everything in his own way sounds a bit extreme and not welcoming.

The big question here is how much can we trust fellow CPAN authors to make the right decisions, can we rely on their work? Can someone, who put's a lot of attention for the details of his API, rely on modules with imperfect APIs, perhaps spoiling his own work and not become insane? The story of the phalanx project shows that there are no easy answers to these questions, but I believe we can do better than rewriting everything from scratch each time.


Anonymous said...

Part of this has to be we have to stop tolerating installs that require force install and make it easier for core bits like TT, URI, CPAN to accept patches from the community.

I'm sure you've done it, you struggled for a while to get Catalyst or something installed, said, "okay, done, works for me now" and moved on. If every time you had trouble with a straight up install you had time to pause and work out why and offer a patch that got quickly processed it would help. Some projects, like Moose are great about this, unfortunately some core bits are maintained by unresponsive authors. We need to change this.

Ovid said...

I don't know enough about the capabilities of Mojalicious::Lite to know that it's the best solution to this problem, but for those willing to dip their toes in the water and don't want to struggle with the dependency problem, it's far, far better than CGI and heredocs.

If we want to encourage people to learn Perl, lowering the barrier to entry is very important. If they like it enough to keep using it, they'll learn what they need to do. If they don't, it doesn't matter.

zby said...

I agree about the lowering the barrier point - but this can be reached by two ways - one is internalizing all the dependencies (i.e. rewriting) - the other is bundling your solution with the external dependencies and making sure that they behave. The first way is easier - but with the second there come more benefits.