in reply to Re^5: File::HomeDir strange behavior Perl 5.28
in thread File::HomeDir strange behavior Perl 5.28

I agree. People want to use the portable distribution because they want it portable. If I carry a Perl installation around on a memory stick, then it makes sense to have my_data on said stick.

berrybrew, on the other hand, is targeted at people who want to run different versions of Perl on the same machine. The Perls need to be isolated from each other, but not from the user/OS environment. In this case I would expect the "traditional" Windows implementation, if only because this is how perlbrew does it.

  • Comment on Re^6: File::HomeDir strange behavior Perl 5.28

Replies are listed 'Best First'.
Re^7: File::HomeDir strange behavior Perl 5.28
by stevieb (Canon) on Nov 02, 2018 at 13:40 UTC

    Hey haj,

    So you're saying berrybrew should go with the "Windows" method as opposed to the "Portable" one, yes?

    This is the very first time I'm hearing about this situation, so I want to get as much input as I can so I can make the most flexible decision in the design.

    I just released v1.19 yesterday and started a new dev branch, so if we can clear things up, I can get any changes into the next cut.

    Could you have a read of my reply here, and let me know if what I've said as a possible solution makes sense?

    Thanks,

    -stevieb

[reply]

      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.

[reply]

        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]

In Section Seekers of Perl Wisdom