Re^8: File::HomeDir strange behavior Perl 5.28

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.

Comment on Re^8: File::HomeDir strange behavior Perl 5.28

Replies are listed 'Best First'.
Re^9: File::HomeDir strange behavior Perl 5.28 by stevieb (Canon) on Nov 02, 2018 at 20:45 UTC
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.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^9: File::HomeDir strange behavior Perl 5.28
by stevieb (Canon) on Nov 02, 2018 at 20:45 UTC

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.

[reply]
[d/l]
[select]