1. I am distributing this module in a application. I dont want to place the entire cpan volume in my application.

2. All I need it to do is read a tabbed file so installing over 8 modules to just read a file is crazy.

3. If a problem occurs tracing through tons of modules to find out exactly what is wrong is nuts. 4. Because it gives me experience and increases my perl knowledge.... I hope :)

1. Use PAR to distribute Perl applications. That will take care of all dependencies, including distributions with compiled components.
2. If all you need to do is read a tab-delimited file, then you should be using Text::xSV. It is PurePerl and deals with a number of issues I'm sure you haven't considered.
3. If a problem occurs, 99% of the time the fault will lie in your code, not in code from CPAN. That's because the code from CPAN has been tested in more situations that you will ever have the misfortune of running into.
4. Increasing your Perl knowledge is a wonderful thing. However, what I would not like to see you distribute an application with bugs that could have been avoided if you had simply chosen to use a well-tested module instead of rolling your own. CPAN exists for a reason; use it!

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

I am aware of par. Its a tool that many people have had successes and difficulties when using it. There is an article somewhere on here about developing with it. On the other hand I have had terrible luck with it on os X. Any modules that have xs seem to fall apart on me.

You seem to be a bit confrontational about what I know.... Let me assure you that on these files there is nothing that I haven't considered. Being users cant access them period being they are extracted from a MPQ archieve and if they do any line ending but x86 crlf causes them to become unreadable. The files themselves are table dumps. And many contain close relationships with one another. Now ideally using a real database would solve my problems and the tools would be there. But I would have to add an addition 10mg to the distribution. Which is something I dont want to do.

As far a cpan modules go you can google a million installation problems. Which is what I meant about code problems. And as far as macs go installing on 10.2 and 10.3 the fixes are different especially if the module involves the curses libs. Perl itself on 10.2 and below uses a older perl with can cause problems in the arena of distributions. The DBI module itself doesn't install correctly. Which makes any modules that use it fail. Believe me if I in all certainty knew that I could use the modules right off cpan. I am lazy enough not to roll my own, I follow the perl mantras when I can, but this is not the case.

As any C programmer from ages past knows to keep your own "libraries" of code that they constantly use. If something doesn't quite fit the bill modify it and call it good. Which in this case is where I am at. Nothing quite fits the bill and after looking I could add 12 modules to get done what I want or write 600 lines that does exactly what I need nothing more nothing less. I just thought it would be a good idea to model the interface like other databasing modules.

As far as bugs go that is part of programming. We all do our best.. to write it once and forget it. But in my 20 years of programming, not myself I nor anyone I have meet has been able to pull it off. So business as usual receive a bug report fix it. And honestly I believe I will have more problems with the glue code and my objetive-c than with the perl stuff.