-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating Vendors with chocolatey #442
Comments
I've been weary about chocolatey, as previously they've had a complete lack of moderation and verification of packages (including cmder), the complete opposite strategy compared to how Linux distros handle their packages. It seems that chocolatey is now working on moderation, I may consider it, but where will cmder fall into this, will we distribute just conemu + cmder tweaks and let choco handle everything else or shall we push for allowing optional vendors which we can look after in https://github.com/cmderdev/vendors? Or even a completely different option? Even in the Linux world there isn't just 1 package manager. |
I didn't know about the moderation. I'm just worried about replying on it and then finding packages we want aren't updated. Apparently it's a decentralised format so we could in the long run host our own packages we or anyone to host their own approved packages. I think a good idea would be to have cmder releases as a solid "run this and start work" set of packages and tweaks. We happen to use conemu and psGet. psGet seems to be using the chocolatey format. we might as well pull our stuff with that. Perhaps we approve what ships on vendor/sources.json and after that it's on the user. This way those PR's about ruby and node we could just say add those choc packages to your personal sources and cmder will use it. Maybe we wait and see what PS5.0 drops. it might just be for PS modules or MS might create a whole package ecosystem. I assume that'll be with W10. I'm familiar with fedora and with yum you can install a collection of packages like |
This is kind of where I'm going with the vendors repo, we have a base set of 3rd party packages and optional packages that can be added in by us or users after we verify they do indeed work. There's no reason we can't include the ability to have PS modules integrate these packages, especially as it seems to be just adding their own Env variables most of the time. Thinking about it, chocolatey packages are available system wide once they're installed, meaning users would have already been able to access them through cmder anyway, which was part of the reason why I closed the original issue. |
Just thinking about making an
Update-vendors
function to check if there's a~/.cmder
json file we can hold user custom settings, vendor packages and powershell modules to get. Use that to overwrite out vendor/sources.json. The build script can call out to this specifying just vendor/sources.jsonIt occurs to me we might just end up rewriting another package format to deal with version and whatnot. Should we revisit using chocolatey for vendors, psGet/native install-module for powershell and leave it at that?
Refering to #42
Since then we've started pulling vendor packages ourselves with build.ps1 and MS have given Chocolatey its blessing and this seems like it will be the windows package format. See the about and oneGet
The text was updated successfully, but these errors were encountered: