Enhancement - Make the collections compatible with PowerShell script about privacy.sexy HOT 5 CLOSED

I have been thinking about it, and I'm sorry that I conclude to not implement it. It brings lots of complexity and requires big effort. If someone else wants to contribute, feel free to re-open the issue. I'd suggest to clone privacy.sexy and do a very simple PoC for review before starting with something bigger.

P.S.: Win10-Initial-Setup-Script was a great project, but lacked a lot of scripts and does not offer any nice UI. If you fork it and copy/paste PowerShell scripts from privacy.sexy I'd not mind 👍🏿

from privacy.sexy.

Thanks for the suggestion, a good one 👍🏿.

I like the idea. I think a nice step towards it would be having some kind of scriptFile: scripts/script-file.ps1 property for each script and point to files & keep metadata in the yaml. I explain why in challenges part.

A solution like #53 is still required as the generated script is still batch and PowerShell is wrapped in batch commands in the final generated code. The primary reason to generate batch is to make the script file more available (some OSes block running PS).

The advantages

• Portability without requiring the GUI as you mentioned.
• Getting some kind of syntax highlighting and IDE support when we're developing them.

The challenges

Metadata

Enforcing a scheme for metadata as you mentioned. It's not as easy as and clear as the yaml file. PS1, bash and batch have different comment syntax that are all used. We'll need specific parsers for PS1, batch and bash.

Maybe one way to make it unified and easier would be to keep the yaml files for metadata but just have an option to point to a file instead of inline scripting. E.g. file: scripts/script-file.ps1. It would require a custom webpack loader that'll resolve those files and load them into the memory in runtime.

Shared functions

In collection yaml files we have scripts that call a yaml defined function such as UninstallStoreApp. So how can we handle the dependencies if we want to use repetitive code with different parameters, just like uninstalling system apps? Even if we go with single file per script e.g. Uninstall-Edge.ps1, Remove-OneDrive.ps1 or with one big PowerShell. Some complex parsers would be required to generate clean scripts with their dependencies.

from privacy.sexy.

The challenges

Metadata

Enforcing a scheme for metadata as you mentioned. It's not as easy as and clear as the yaml file. PS1, bash and batch have different comment syntax that are all used. We'll need specific parsers for PS1, batch and bash.

Maybe one way to make it unified and easier would be to keep the yaml files for metadata but just have an option to point to a file instead of inline scripting. E.g. file: scripts/script-file.ps1. It would require a custom webpack loader that'll resolve those files and load them into the memory in runtime.

I still don't see the necessity of the yaml files. If we only save the "point to a file" in a yaml file, we can easily generate such files using a script.

Shared functions

In collection yaml files we have scripts that call a yaml defined function such as UninstallStoreApp. So how can we handle the dependencies if we want to use repetitive code with different parameters, just like uninstalling system apps? Even if we go with single file per script e.g. Uninstall-Edge.ps1, Remove-OneDrive.ps1 or with one big PowerShell. Some complex parsers would be required to generate clean scripts with their dependencies.

I think "one big PowerShell" is the best way to solve this problem. In fact, we don't need to generate a clean script, we only need to generate a list of functions that need to be executed, just like Win10-Initial-Setup-Script/Default.preset.

from privacy.sexy.

I think "one big PowerShell" is the best way to solve this problem. In fact, we don't need to generate a clean script, we only need to generate a list of functions that need to be executed, just like Win10-Initial-Setup-Script/Default.preset.

I don't agree with you here, technically you are right with functions it will be more easy technically but for power-users like me what I love with this project is to have "quickly" the source code I want and only it. Not a big blob of source code containing all the functions I will never use with a PS1 script that just call the functions I need.

When I generate a power-shell script here it's because I need this code and from that I will customise the values, the variables without the need to parse thousand lines of code I don't need /want,

Again from the point of view of a maintainer of such repo it's lot more easy to maintain a big blob with all the functions in another ps1 script but since many repos here already offer such format that I don't see the need for another clone of those repos (btw those repos are useful but are more targeted to end-users or people that don't want to see the source code or change it.).

Regards

from privacy.sexy.

I don't agree with you here, technically you are right with functions it will be more easy technically but for power-users like me what I love with this project is to have "quickly" the source code I want and only it. Not a big blob of source code containing all the functions I will never use with a PS1 script that just call the functions I need.

Our code is mainly simple functions that calls other functions. Therefore, if we write a simple dead code remover to analyze the calling relationship of the function, then we should be able to get the source code we want and only it. If the functions become too complicated, we can also consider writing a dead code remover by calling an analyzer such as PSScriptAnalyzer.

from privacy.sexy.