When trying with Strawberry (portable), perl -MFile::HomeDir -e "print $File::HomeDir::IMPLEMENTED_BY;"
gives me Portable::HomeDir
If I remove/rename said module (...\perl\vendor\lib\Portable\HomeDir.pm), I get the expected File::HomeDir::Windows.
It might make sense for berrybrew to do this locally.
(Update: crossposted to https://github.com/stevieb9/berrybrew/issues/121) | [reply]
[d/l]
[select] |
Thanks for the issue report, soonix!
I'm a bit confused as to what is desired for berrybrew here. Are you wanting berrybrew to point to C:\Users\USER\AppData\Local, or portable_install_path\data?
What do people thinks makes more sense?
Since I'm honestly only a Windows user in rare cases (testing my own software, mostly, and, well, developing berrybrew ;), I'm not sure of the benefits of either way.
In either case, if people thinks it would be better to have an option to return all portable editions in berrybrew back to the default File::HomeDir on each install, I'm all ears. That said, I would make it user configurable via a config file directive, where the current method is default, and the user would have to set a flag to have the Portable functionality removed (and it would be global, occurring after each install of a new instance).
I suppose I could add a new berrybrew install x.xx -win_home or some such flag as well so that each install could be customized, if you think that makes sense. In any case, it would have to be non-intrusive to the user.
| [reply]
[d/l]
[select] |
I think I'd prefer berrybrew removing the Portable::HomeDir by default. However, CPAN and cpanm both use File::HomeDir->my_home, which means it would be difficult to have different configs for different versions. This probably would only be a minor gotcha, but I see the impact would be greater than what I thought when I wrote this. A config directive is definitely a good idea.
| [reply]
[d/l]
[select] |
| [reply] |
Improbable. Removing Portable::HomeDir might break a script or an application, if that expects File::HomeDir's "portable" behaviour. OTOH having it in effect breaks scripts/apps that expect the "normal" behaviour.
| [reply] |