Per-package hooks which can modify the config

[jayvdb]

Spawned from #42 (comment)

The pnpmfile.js approach is very powerful. At each layer of the package tree, the data structure is given to the hook which can modify it, and pnpm uses the modified structure. For context, in pnpm this is critical as npm authors often forget to declare a direct dependency because it is installed by another declared dependency. In a flat node_modules it doesnt matter, but it breaks pnpm. However I see the same underlying problem in choco -- the packages are often poorly maintained, and either we create our own packages for everything or fix them at runtime. The latter approach has a lower ongoing maintenance cost, and it isolates the problems and the fixes needed, so it is easy to then report bugs with solutions upstream.

At the moment, Fudge only has two levels of nesting - the top level, and then each entry in the Fudgefile. I expect that will change to three levels when dependency tracking is added. nuspec format already describes dependencies so that could be added quite easily. For real choco dependencies, it gets a bit more tricky #57 .

[jayvdb]

On the topic of per-package hooks, I have a very hacky hook system implemented using the post install hook.
Hooks can be seen at https://gitlab.com/coala/package_manager/merge_requests/169 and coala/coala-bears#2910

[jayvdb]

Another use of hooks, which requires modification of the config at runtime, is creating fake choco package entries if software is pre-installed.

I am doing that for AppVeyor CI, as it has a lot of pre-installed software https://www.appveyor.com/docs/windows-images-software/ , increasing the speed of the setup, and sometimes it isnt even possible to install the choco package over the top of the pre-installed software. I am doing that using an AppVeyor specific Fudgefile which uses locally created fake nupkg with package names matching the entries which will be processed by the real Fudgefile , which causes Fudge/choco to process those very quickly as it is a no-op. It would be nice to inline that logic a hook which runs before each package which would replace the entry source with the built nupkg if the host is AppVeyor.

[jayvdb]

A related problem, perhaps worth of a separate issue, is that hook pre.install is called for -adhoc use of install, and there is no easy way for the hook to tell if it is being called from an -adhoc invocation or not.

[jayvdb]

I am doing that using an AppVeyor specific Fudgefile which uses locally created fake nupkg

I have found that the current hook system does implicitly provide $config, and it can be modified during pre, and those modifications are used during the install. I guess this is a side-effect of using Invoke-Expression, which PSScriptAnalyzer so dis-likes. So this, and dynamic args/params (#42) become much less important IMO.

However, I believe the $config is currently an immutable data structure, or at least the $config.packages items (hashtables?) cant have new attributes added to them, and they are lacking standard attributes like Source if they were not provided in the Fudgefile. My hack around that was to set each package to have sources="...." in the Fudgefile, so that I can change the value during the pre hook.

So it would be nice if the $config was pre-loaded with null/empty values for all the common fields, and the rest of Fudge knows to ignore null/empty fields. Ideally this doesnt enforce the fields available, as I am mis-using Fudgefile to include an extra field to help me set up AppVeyor dynamically. I could survive if this hidden/unsupported feature was lost; I can find another solution easily.

What would be even better is if the data structures were completely mutable, so that new attributes could be added to the dicts.

In the context of per-package hooks, if they are implemented the same way, I guess "$package" would be an implicitly available variable which again would be mutable, in addition to "$config" being available.