Because it's a centralized repository, and having it in the registry allows much easier management when upgrading.

It's also a lot less taxing (code and process time) doing quick registry reads than it is opening, reading, parsing, converting from and closing a JSON file on each run in C#.

It also ensures the configuration is always in a single, specific location, so it can be read and modified without having to figure out where the installation is located (by parsing and then searching each PATH for the berrybrew.exe binary, then loading the file from the data directory).

Makes testing a whole lot easier as well.

You can still utilize the config file if you please:

• Modify a configuration file variable
• Run berrybrew options-update-force hidden command to reload all options from the file

It still utilizes the registry though, but the process without using the hidden command to force reload the options, the config file is read only once... upon first run of the software.

The main reason that made me change my mind from file to registry is that in this version, registry work was required for other features... UI at startup, installer/uninstaller data storage, and the modification of the .pl file association work. Once the registry became involved, migrating the config over was a natural progression.

The next version is dedicated 100% to drastically increase test coverage. No new features will be added, unless they are a side-effect of finding something while adding these new tests. I plan on adding a minimum 10x the number of tests I have now. This will allow me to find a lot of areas where I can make the code a whole lot better and more efficient, and provide better scoping for error handling. Getting the registry stuff implemented in this most recent version allows all of the new testing to be future proof.

I see

It's also a lot less taxing (code and process time) doing quick registry reads than it is opening, reading, parsing, converting from and closing a JSON file on each run in C#.

Makes testing a whole lot easier as well.

Hmm, doubtful

It also ensures the configuration is always in a single, specific location, so it can be read and modified without having to figure out where the installation is located (by parsing and then searching each PATH for the berrybrew.exe binary, then loading the file from the data directory).

$HOME/.berrybrew is just as specific and doesn't require much figuring out

berrybrew is not meant to be a user-specific software, it's system wide, so there's not much sense in placing a configuration file inside of a user's home directory. This is due to how PATH env var works on Windows. Two users can't simultaneously be using two separate versions of Perl, so I don't see much sense having multiple instances of berrybrew floating around (ie. instance per user). The system paths takes precedence over user paths, so if someone installs Active or Strawberry Perl as a system perl, none of the berrybrew perls would take effect. This is unlike Unix, which is why Perlbrew can work the way it does (per user).

That said, I'm not even a Windows user, I use it only for developing this software, so if you have any suggestions on how to make it better, I'm all ears.

Might I ask what it is you have against using the registry? I'm legitimately curious. I'm always interested in hearing from others in order to make my software better.

Update: I would love to learn how to make it so that A) it would work per user, and B) refreshing the environment on each change wasn't necessary. I have tried repeatedly to achieve these goals, but obviously, to no avail.

It's not easy to tell what %HOME% means on Win.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}