Using my version of a cpan module

[WPeacock]

I have found it necessary to expand upon a CPAN module. (Unicode::CharName goes up to Unicode 4.1; I need some characters from Unicode 5.0 & 5.1).

I've made the changes needed and have my own CharName.pm module.

I now would like to use it with my various Perls. I currently use

Strawberry Perl for Windosw

git for Windows MINGW64; My .bashrc sets $PATH to Strawberry perl and $PERL5LIB=/c/Strawberry/perl/vendor/lib:/c/Strawberry/perl/site/lib

WSL Ubuntu

Where should I put my version of Unicode::CharName, so that it over-rides the ones installed by CPAN.

[haj]

As always, there's more than one way to do it. Also, it depends on which features you need, and whether you would be able to change a bit of your setup.
• You could just build a new package containing your own CharName.pm and install it. Strawberry Perl contains all the tools you need. I don't know why your PERL5LIB has a different ordering of the vendor and site paths than usual - you might need to reverse that.
• You could also check whether the core module charnames fulfills your needs. It is as up-to-date as your Perl version: Unicode version 5.1 came with Perl 5.8.9. It provides character names with the charnames::viacode function but no equivalent to the ublock.

[VinsWorldcom]

I think the PERL5LIB path is weird since normally it isn't needed - it's in @INC. But OP is using the Git for Windows perl, not Strawberry (C:\Strawberry\Perl\bin\perl.exe) but wants to use the libraries installed in Strawberry with the Git for Windows perl. So he has to configure PERL5LIB with paths that would normally be in @INC, but the Strawberry paths aren't in the Git for Windows perl @INC.

A bit of kludge if you ask me, I just use PowerShell (way more capable than cmd.exe and can be customized to be like bash) so I don't need to use Git for Windows bash and thus never have the perl conflict issue.

[WPeacock]

Actually, when I said "My .bashrc sets $PATH to Strawberry perl" I should have quoted my (now modified per ^2) .bashrc:

if [ -x /c/Strawberry/perl/bin/perl.exe ] ; then
 export PATH="/c/Strawberry/perl/bin:/c/Strawberry/c/bin:$PATH"
 export PERL5LIB=/c/Strawberry/perl/site/lib:/c/Strawberry/perl/vendor
+/lib
fi

So, my git bash is really using Strawberry Perl instead of MinGW's Perl that doesn't have CPAN

[VinsWorldcom]

I too use Strawberry and use local::lib. To first get it "installed":

perl -Mlocal::lib

Not sure if I needed to create the C:\Users\VinsWorldcom\perl5 directory of if it did that for me. But when you run the above command, it prints out some environment variables to set and you can add them through Control Panel -> System so they're permanent. Then you can install modules in the C:\Users\VinsWorldcom\perl5 and your PERL5LIB environment variable path should have your local::lib directory at the beginning.

NOTE: If you're using Git for Windows bash, it comes with a perl which is *not* Strawberry and running perl from Git for Windows bash (at least for me) uses its local perl, *not* Strawberry.

[bliako]

IMO the approach should be to extend the module you are now trying to modify to, e.g. Unicode::CharName::More. That said, I will use the author's excuse for not posting any more code now: # XXX: could use a binary search, but I am too lazy today... my excuse is that I am going for swimming in a few minutes in the deep blue and with good company.

On the other hand, installing said module failed for me (linux) because dependency Unicode-String-2.09 fails with Can't use 'defined(%hash)' (Maybe you should just omit the defined()?). So perhaps using the charnames haj mentioned could be wiser and if you really need a ublock() function extend said module.

[markong]

This make more sense: in general if you want to customize some installed module which uses object orientation, you should subclass it and override the relevant bits and pieces.
This also prevent you the hassle of mantaining a local modified copy of modules and playing with your OS's @INC definition to let perl having access to their location.

[bliako]

what's best practice for non-object-oriented modules? (like the ones mentioned above.) Do you just use it and then provide your own improved subs which subsume existing ones?

[dsheroh]

Note to potential answerers: This question has been crossposted on Stack Overflow.

(Note to WPeacock: There's nothing wrong with this, it's just considered polite to inform people so that they can avoid posting duplicate replies or, if someone else has a similar problem in the future, they can benefit from all replies in both places.)