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.

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.


Enjoy, Have FUN! H.Merijn

"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?

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

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
[download]

Opinions/improvements welcome.

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.