Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Monday September 05, 2005
12:01 PM

Algorithm::Dependency must die!!!

[ #26603 ]

Right. That's it. I've really just had enough with Algorithm::Dependency and it's little issues and things it doesn't support, and which can't easily be added on. I still think I designed a really great algorithm, but in turning it into a module I made a lot of stupid API decisions, and now it's embedded so deep in so many things I pretty much can't escape.

Extending it feels like extending Java code. There's a zillion damn classes, and all of them are tiny with dependencies all over the place.

Writing the adapters for JSAN was the last straw. It doesn't like working directly with objects (which resulted in Alg::Dep::Object being written by someone else) it doesn't support Sources that need to be resolved incrementally, so you have to load the entire world in advance every time.

Casting around for ideas, I discovered Graph.pm and finally took the time to read through it.

As usually, I find out that the problem I solved on a whiteboard on the loungeroom floor watching random mindless motorsports has all sorts of official terminology attached to it, like "graph theory" and "vertice" and "edge" and so on.

So I'm junking Alg:Dep and starting a new design. And _this_ time it's going to...

- Use the correct terminology
- Support objects (including anonymous ones)
- Support incremental resolution
- Support versioned dependencies
- Support vertice values (multiverticies I believe it's called)
- Be less of a pain in the arse to integrate into things like Class::DBI
- Use an API that will be much more portable to Perl 6 and work better once it's ported.

And so on and so forth. It's a big ask, and I'm expecting it to take about a month (ok, at _least_ a month) for a complete design to gel together in my head enough to be confident of the design.

Fortunately, I'm already confident about the core Alg:Dep algorithm, and it will be staying. But it's the next layer out that needs some heavy refactoring.

In fact, the result of a dependency call of the same system ported from Alg:Dep to whatever the new system is should be both deterministic and produce the same list in the same order. I want clean upgrades too.

The filling is great, I just want better buns. And this time around I'd like a plate. And maybe a coffee.

So, have you ever tried Alg:Dep? Have any issues, comments or problems with it? Feel free to comment.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • (in fact, two days prior to YAPC::Europe). I wanted to generate dependency trees for CPANTS that showed the sum of all dists required by each dist.

    I played around a bit but didn't get it working (mainly because I couldn't figure out how to build a source list from a DB - but this seems to be caused by what you call 'loading the world'). I didn't want to spend to much time on it, as I had other stuff to do (like writing slides...).

    I look forward to a new release of Alg:Dep, as I definitly want to include sai