if we're to imitate the syntax in my source it begins: our %config = (
You can get this kind of output from my code by changing Data::Dumper->new([$CONFIG],['$CONFIG']) to Data::Dumper->new([$CONFIG],['*config']) (change the variable names as you like); you'd just have to prepend the our yourself. See also the Data::Dumper docs.
What makes it very difficult is that we seem to be acting on perl syntax itself.
Yes, that's a pretty complex topic, so soonix's suggestion to use a different configuration file format is a good way to avoid that issue.
Why is my syntax on the config hash clashing with that provided by man Config::Tiny and haukex?Variable "$config" is not imported at template_stuff/utils2.pm line 61 +. Global symbol "$config" requires explicit package name (did you forget + to declare "my $config"?) at template_stuff/utils2.pm line 61.
You've done use config2;, which should give you a hash %config, which you can confirm if you comment out the line with ->write: do you see the output of print Dumper \%config;? Then, you're doing $config->write, which means "call the method write on the object $config" - not the hash %config! That's why Perl complains about the missing variable $config.
It's possible to create a new Config::Tiny object and then copy over the config from config2.pm's %config into that object. However, I am wondering what the goal of your code is here. Are you trying to automate the conversion from config2.pm into an INI format? If the config is long, I can understand that, but if it's as short as you showed, why not do that step once, by hand? You can then use a method similar to what I showed to create a redacted version, or, again, since that's something you'd probably only be doing once (?), you can do that by hand as well.
Taking a step back: My understanding so far is that you want to provide your code for download for others to use, is that right? And you're figuring out a way to disentangle the stuff you've written for yourself (config files etc.) from the general stuff that you want to distribute to everyone? That's pretty common, and a situation I've been in plenty of times. I've found the best approach is to look at it from a different angle and put yourself in the user's shoes, as if you knew nothing about the internals of the package: what steps would a user who downloads the package have to take to set it up? How would you describe those steps in your README for the user to follow? And then, what do you as the developer have to provide to make that as easy as possible?
In reply to Re^3: redacting from config hash
by haukex
in thread redacting from config hash
by Aldebaran
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |