Skip to content
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

Closed
Jackbennett opened this issue Mar 25, 2015 · 3 comments
Closed

Updating Vendors with chocolatey #442

Jackbennett opened this issue Mar 25, 2015 · 3 comments

Comments

@Jackbennett
Copy link
Contributor

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.json

It 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

@MartiUK
Copy link
Member

MartiUK commented Mar 25, 2015

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.

@Jackbennett
Copy link
Contributor Author

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 webserver and it'll grab apache php5 etc for you. I've been thinking of cmder a bit like that.

@MartiUK
Copy link
Member

MartiUK commented Mar 25, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants