Implement a better install routine to handle required runtime dependencies of windows in install.ps1 for slight.exe #408
Labels
📐 proposal
A concept/proposition, no design work has been done yet
Describe the solution you'd like
Currently for a Windows 'execute' of the slight.exe, (which is 'installed' via a ps1 script to handle adding it to PATH and used in CMD) requires other dependencies to run shown here #378. Most systems with/without build tools (usually) come with a vendor copy of OpenSSL (primarily Linux, MSYS or git bash/gui) to link with your tools and run your developed bins. However, most systems are NOT expecting you to need most these tools Out-The-Box and therefore excluded.
It would be useful to have the 'install.ps1' script automate the help in discovery and resolution for slights' OpenSSL dependency. Thus making it way less a head-ache to manually have to check for or install OpenSSL, because lets face it, that process is tedious enough to cause multiple breaks along the way and most of us are just too lazy...
Therefore, breaks in slight.exe can simply occur due to:
NOTE That this 'install.ps1' does produce expected behavior by expecting OpenSSL to be called dynamically, ergo it assumes OpenSSL is installed, in the environment user path and ready to be invoked. A modification of the 'install.ps1' to not assume this, is the goal. Most end users(YOU), use or have their versions and compiled builds of OpenSSL made specifically for their runtime environment. Thus to accommodate for any custom setup that needs to run for a bin in their environment, like using remote bin(s) for development. Hence, a custom OpenSSL build and environment used as a dep for bin x specifically, will not be configured to work for bin y, unless configured to do so.
The manual solution without implementing into install.ps1 (may still break, may get things working):
A way less hair-pulling method can and should exist.
Trust me, no one solution is concrete nor friendly enough (at least to me) to accomplish this correctly, but we can certainly allow for any break handling of anomalies by modifying the 'install.ps1' script. I know I don't want to be dealing with the manual solution every time.
Additional context
My Expectations:
The Problem:
Windows (IMO) is the worst on making sure runtime deps are available when a bin makes a call to a linked dep , because most redistribution runtimes that contain development build tools such as OpenSSL are; not properly installed, exist by default or not exposed to PATH.
Following the simple (<- hahaha) ways to obtain OpenSSL here, specifically explained as how to acquire OpenSSL to use for building rust-openssl as a needed dependency.
I would like to see each windows method added as part of the install.ps1 script for the slight.exe binary as options to set up before the slight install finishes. At the minimum detect and warn about inconsistency in dependency existence, and at most provide the full resolution process of acquiring OpenSSL when it cannot be found or not in current user environment. This will make an easier way to inform users of breaks and manage optimal solutions for missing dependencies before slight install finishes.
I personally will assign myself to get started in testing the methods for windows platform only ATM, and how to implement them into 'install.ps1'.
How I will set, use and test an Environment:
I can post my findings here, or may I recommend to create a project for workflow.
Mock-up of proposed 'install.ps1' script additions for validations and installs of OpenSSL:
The text was updated successfully, but these errors were encountered: