Promoting Text::CSV to base Perl?

[mldvx4]

Greetings to those who check PerlMonks daily, and everyone else, too, from those of us with short, random user names.

Whom should I ask about an proposing official consideration of promoting Text::CSV to the Perl base, to consider affording it the same status and dissemination as say Getopt::Long or Data::Dumper? The reason for asking is that it seems that basic upstream AWK has recently gotten integrated CSV support now:

Kernighan, now 80, offhandedly mentions in the interview that he has also patched something "quick and dirty" to let AWK handle CSV files.

That CSV support will likely percolate down to all the AWK variants someday, too. So it would be very nice to add Text::CSV to the base of Perl to keep up with the competition so to speak, though I am unsure of the process to ask, whom to ask, whether it has been considered already, and the overall merits/demerits of the idea.

Myself, I only learned AWK rather recently and have gotten by for ages and ages with Perl for such tasks. Generally, perl -a -p -e ... and perl -a -n -e ... have done the job well for all these decades except when encountering with CSV files. Adding Text:CSV to the base would be a boon. Manually installing Text::CSV from CPAN or the relevant repository each time is feasible for many people but not all. Many don't administer their own boxes or have very helpful system administrators. So it would be perk for them to have it in the base, not to mention an opportunity for positive press about keeping with the times and "data science" and such.

tldr; keeping up with AWK

[Corion]

The people to lobby for that would be the Perl5-Porters. One problem that Perl faces is that the continous maintenance of things in the Perl core puts a burden on the Perl developers, hence they are not keen on taking on things that can be installed from CPAN or your distribution package manager instead.

Installing modules for the current user has also become much easier, and there is at least talk of actually getting (something like) local::lib into the Perl core. This would make locally installing modules much easier.

If you are a developer, or a person writing Perl code, you should also be able to download the two .pm files from CPAN, as Text::CSV does not need any external dependencies beyond what comes with Perl.

[Tux]

I think I can tell the net-result, whatever path is taken: it won't.

I am both a perl5 porter *and* the author/maintainer of Text::CSV_XS. Text::CSV follows Text::CSV_XS and having Text::CSV in core would thus imply to also have Text::CSV_XS in core.

The perl5 porters share the thought that if a module does not require deep CORE internals, and Text::CSV_XS does not require any core specific changes, and is (relatively) easy to write as a (CPAN) module, they/we prefer that over integration. This rule will instantly be broken if the core itself would have great use of this module.

The ease-of-port for Text::CSV_XS is guaranteed by Devel::PPPort, which is part of CORE since 5.7.3.

Having a module in CORE often makes sense to an outsider/end-user, but the burden of having it in CORE is a real pain for both the porters and the author of the module. I can tell, I also have modules in CORE, and it raises the amount of time to maintain a module.

All of the above has nothing to do with the quality or usefulness of a module! Take another example: DBI. I personally would have no job if I would not have it, but having it well-maintained makes it extremely easy to add it from CPAN to any perl installation.

[mldvx4]

"The people to lobby for that would be the Perl5-Porters. "

Thanks.

"One problem that Perl faces is that the continous maintenance of things in the Perl core puts a burden on the Perl developers, hence they are not keen on taking on things that can be installed from CPAN or your distribution package manager instead."

Fully understandable. I can appreciate that balance.

"Installing modules for the current user has also become much easier, and there is at least talk of actually getting (something like) local::lib into the Perl core. This would make locally installing modules much easier."

Perhaps that would be the way forward. If it is made easier to install local modules, then it would remove the question of adding to the core and thus be better than just debating one module at a time adding to the maintenance each time.

"If you are a developer, or a person writing Perl code, you should also be able to download the two .pm files from CPAN, as Text::CSV does not need any external dependencies beyond what comes with Perl."

Yes, I write Perl scripts at irregular, unpredictable intervals and have used that trick before albeit with some other modules. Sometimes those intervals are far enough apart that I've done a completely new installation, sometimes even a different distro, and then have to bring in the unique constellation of modules unique to my activities. Since I administer my own machines in recent decades, or have helpful sysadmins, it is usually possible to use the convenient package from the repository or the CPAN module as a fall-back. I'm thinking of the situation that newer people will find themselves in, so maybe local::lib might be considered. Is there anything to test that would help either direction?

[eyepopslikeamosquito]

Myself, I only learned AWK rather recently and have gotten by for ages and ages with Perl for such tasks.

This is the opposite to me!

Back in the late 1980s (when programming books were really important;-) I remember eagerly reading the (grey) AWK Programming Language from cover to cover ... and loving it ... then along came the the pink camel, and I just couldn't bring myself to go back to the grey book after reading the pink one. :)

Seriously, I've argued successfully at multiple workplaces that it's better for an organisation to write everything in Perl rather than a motley mix of shell, awk and Perl because it scales so much better as programs (inevitably) grow from hundreds to thousands to hundreds of thousands lines of code.

See Also

• Unix shell versus Perl
• sed/awk/grep to Perl
• Need advice in for perl use as awk replacement
• Using Perl instead of awk!
• Awk and Perl unique features

[eyepopslikeamosquito]

So it would be very nice to add Text::CSV to the base of Perl to keep up with the competition ... an opportunity for positive press about keeping with the times and "data science" and such

After some random googling on this topic, I am unconvinced of the marketing value of adding CSV support to the Perl core.

I'm happy to be corrected, but suspect that YAML, XML, and JSON, for example, all have far higher sex appeal than CSV -- at least those three are listed at Data exchange on wikipedia while CSV is not.

I'm also unsure of the best way to find out what data exchange/data serialization formats are currently supported in Perl core. Based on How To Identify or List Core Modules, I tried these commands just now on perl 5.38 on Linux:

$ corelist -v 5.38.0 >corelist.tmp
$ wc -l corelist.tmp
649 corelist.tmp

$ grep -i JSON corelist.tmp
JSON::PP                                     4.16
JSON::PP::Boolean                            4.16

$ grep -i YAML corelist.tmp
CPAN::Exception::yaml_not_installed          5.5
CPAN::Exception::yaml_process_error          5.5
CPAN::Meta::YAML                             0.018
TAP::Parser::Result::YAML                    3.44
TAP::Parser::YAMLish::Reader                 3.44
TAP::Parser::YAMLish::Writer                 3.44

Opinions/improvements welcome.

[mldvx4]

Or, if there is a back story / baggage / history I should know about before asking, then please be so kind as to reference it. Thanks.