-
Notifications
You must be signed in to change notification settings - Fork 18
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
RFP - nix #1560
Comments
Package Request ValidationWe have finished some basic validation of this request. The result of this validation can be found below: Request NoticesWe found some issues we could not fully validate without user input, or by human review. Please make any necessary changes when appropriate.
File Validation Output
Please note that this check is currently in alpha, and may not be able to detect everything correctly. |
I'm not sure what to do about this notice, since this package is supposed to be built from source! We do have cross-to-windows builds in CI, but I doubt you will want to use those. |
Chocolatey uses the native installers to install the software. While it's possible to built packages from source as part of a Chocolatey package, it's not something that would be accepted on the Chocolatey Community Repository. If the build requirements are pretty light, it may be accepted. Worthwhile asking in the Community Hub. |
Hmm OK, it sounds like I have misunderstood what chocolatey is. I thought it was more directly competing with the likes of vcpkg, msys (but no mingw assumption), etc. Thanks for letting me know. |
vcpkgs is generally used for managing and building libraries. msys is a development environment. So I'm a little confused. Chocolatey CLI is the package manager for Windows. It manages packages similarly to apt, yum, dnf, brew etc. As mentioned, you should ask about how best to package this in the Community Chat. |
@pauby I was already in the community chat, happy to discuss more there too. Let's get the categorization straight:
I submitted packaging requests to all of these, which is how I learned this information 😅. We should soon have a Nix package for MSYS, but as I said above that still keeps us in MinGW land. I would like to also have a non-MinGW official build for "maximum nativeness", at which point I would be happy to link an official binary here :). But there is still the problem of getting the library deps for that. I see that Chocolatey and WinGet are not trying to help with that (and that's fine! I respect the library vs executable division of labor). Does all this mean a good/best practice to use vcpkg to get the deps, build official binaries, and then reactivate this issue once we have the artifacts you require? |
@Ericson2314 My goal was to try to help with your understanding of what both Chocolatey CLI and Chocolatey Community Repository are, and on how software built from source has been received in the past for the community maintained repository. If you are discussing this on the Community Hub, then having a separate discussion here feels counterproductive. Chocolatey packages can absolutely do what you need. That is not the issue. The issue is whether it would be accepted on the community maintained, Chocolatey Community Repository. My current need is to understand if this issue stays open (i.e. the Community Moderators would accept a package that is built with the artefacts you have) or should be closed. |
Nothing was redundant; I already joined the discord but didn't discuss things there yet.
I am fine closing it for now. I don't think we yet have the needed artifacts. I can reopen it once we do. At that point I think we would be accepted, as Nix is a major software project. |
Checklist
Package Details
Software project URL : https://nixos.org/
Windows port chat room: https://matrix.to/#/#windows:nixos.org
Direct download URL for the software / installer : https://github.com/nixos/nix
Software summary / short description: Nix is a package manager with an currently-in-progress Windows port.
Package Expectations
First of all, we completely understand if it is premature to ask this before our Windows port is finished. (It currently does build, but some key features are missing.)
The most selfish reason we are asking is we'd love more ways to get development environments for Nix as we work on it. The middle reason is the port should still be done, and then we want as many way for Windows users to try out Nix as possible. The most collaborative reason is running Nix on Windows is just the first step; having good package definitions is just as important. We'd love to learn from the and share knowledge with the existing Windows-supporting package managers as much as possible in this regard.
The text was updated successfully, but these errors were encountered: