Comparison of INI-format modules on CPAN

I'm not terribly happy with the state of Perl/CPAN support for the INI file format.

I have this requirement of modifying php.ini files programmatically from Perl like: set register_globals to On/Off, add/remove some extension (via the extension=foo lines), adding/removing some functions from the disabled_functions list, etc. So I would like to find a CPAN module that can just set/unset a parameter and leave formatting/comments alone as much as possible.

Turns out that among a dozen or so of INI modules on CPAN, a few of them do not do writes at all (e.g. Config::INI::Access or Config::Format::INI). And a few that do, write a la dump. That is, they just rewrite the whole INI file with the in-memory structure. All comments and formatting (even ordering, in some cases) are lost. Example: Config::INI::Writer and Tie::Cfg. And, last time I tried, I couldn't even install Config::IniHash from the CPAN client. Not good.

So I ended up with Config::IniFiles. And I needed to patch two features in before I could even read php.ini and write to it properly. This is an old module, which although still maintained, probably needs a rewrite or modernization. One reviewer in CPAN Ratings also wrote that this module fails in edge cases and the test suite is incomplete.

But, at least this module gets the work done. It tries to maintain comments, and even has a host of other features like delta, multiline, default section, etc. Most features seem to be rather exotic to me personally, but then none of the other INI modules on CPAN has the basic features that I needed.


I recently had a similar problem. I made a little bit of superficial research and made some notes on annocpan here:

zhank you, twas informative

Hi Steven!

I'm glad you found Config-IniFiles a good starting point for working with ini files, and thanks again for the enhancements you have provided for it (which I've applied). I should note that I've adopted Config-IniFiles because I've chosen to make use of it for some purposes. I don't remember why I've chosen it instead of an alternative, but it has worked well for me since.

Regarding "This is an old module, which although still maintained, probably needs a rewrite or modernization.", after reading what Joel Spolsky has written in his "Things You Should Never Do, Part I" and "Rub a Dub Dub" essays, I'm not a big fan of completely throwing away a large working codebase and starting over, and prefer a more gradual refactoring, and what you call "modernisation", which can be done incrementally, without introducing too many bugs, while preserving all the knowledge that accumulated in the code, and which is almost always less time consuming. That and non-elegant code can still be left alone as long as it is functional and mostly bug free.

I will accept any patches that are aimed at refactoring or modernising the Config-IniFiles codebase, as long as they pass all the existing tests. I've done some work on cleaning up the Config-IniFiles code myself, but naturally, there's still a lot of work to do, but since Config-IniFiles is working so well for me and for most people, and there are many other FOSS projects I contribute to (and a day job), I'm not too motivated to improve it myself, but like I said will apply any patches I get.

I will also accept patches to add more tests and increase the test coverage, or to handle more edge-cases. Thanks again, and I hope to see more contributions from you.

Hi Shlomi, thanks for commenting. You're right actually. There's just too many work to do, too many existing legacy code, and so little time. Nowadays I mostly also continuously refactor instead of doing rewrites.

Anyway, it's always nice to see modules that are several years or even a decade+ old still being adopted and maintained. Hope to be doing the same in the future. Keep up the good work.

Leave a comment

About Steven Haryanto

user-pic A programmer (mostly Perl 5 nowadays).