Yes, I read that article... With a new configuration option, everyone can have it their way... but the option needs to be implemented, documented, and maintained. If you just change the behaviour, it is more like perlbrew, "something" might break, but I can't think of any valid use case which breaks. If you keep it as it is, then it looks a bit weird for perlbrew users.

Though I do use File::HomeDir and all sorts of Perls on Windows and therefore knew about the behaviour of the portable distribution, I am not affected at all. berrybrew is for testing, and while I'm testing, I use File::HomeDir::Test which avoids the problem.

So, you might want to take that with a grain of salt: Personally, I'd prefer not having to bother with another switch for berrybrew install or a config option. Stuff like this tends to pile up and you'll never get rid of it again. Chose any behaviour, and if someone really has a valid use case (i.e. other than "hypothetically possible") then they can easily delete (or install) the Portable flavour of File::Homedir.

I

• do my very best to not change APIs or functionality after they've been in the public as production-ready without extremely good reason
• always (do my best to) leave the existing behavour as default, and any change to the product must be acknowledged and implemented consciously by the user (ie. no "it worked well yesterday!")
• am seriously pedantic about my documentation for all of my software, so any new config/param etc would certainly be clearly documented
• maintain a robust Changes log for all of my software, so both users and developers can easily find when somethings been added
• keep commits as tight as possible; a commit includes (for the most part) only details surrounding a single piece of something (in this case, an add of a new config var or new command line flag
• mostly keep commits lined up with an issue, so it's easy to track everything part of the change (ie. I generally create an issue for any change I see, need or want to make)

So, I've got the following options to ponder thus far. Possibly just one, some or all:

• config var for global
• new flag for individual install berrybrew install x.xx -win_home (the name of the flag is irrelevant at this time)
• possibly a new top-level berrybrew command (eg: berrybrew home [windows|portable]) (where the option can be left out and the command alone will print out what the current setting is, and perhaps even make it take another arg, a specific version of Perl to operate on an individual instance if desired) (Again, name is more or less irrelevant here. Suggestions welcome).

Note to self (I'm using this as a reference from the issue itself): If we're to go with an option where the portable module can be disabled/enabled, we'll have to create a new storage directory in the root dir, put the file(s) in there, and somehow associate each pm file with the instance it came from.