RFP - nix

[Ericson2314]

Checklist

• The package I am requesting does not already exist on https://community.chocolatey.org/packages;
• There is no open issue for this package;
• The issue title starts with 'RFP - ';
• The download URL is public and not locked behind a paywall / login;

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.

[github-actions]

Package Request Validation

We have finished some basic validation of this request. The result of this validation can be found below:

Request Notices

We found some issues we could not fully validate without user input, or by human review. Please make any necessary changes when appropriate.

• We were unable to find a supported binary file in the download URL. Please make sure that the download URL is correct.

File Validation Output

TrID/32 - File Identifier v2.24 - (C) 2003-16 By M.Pontello
Definitions found:  18376
Analyzing...

Collecting data from file: C:\Users\RUNNER~1\AppData\Local\Temp/software.tmp

Warning: file seems to be plain text/ASCII
         TrID is best suited to analyze binary files!

       Unknown!

Please note that this check is currently in alpha, and may not be able to detect everything correctly.
Humans may also be able to detect other issues with this request.

[Ericson2314]

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.

[pauby]

since this package is supposed to be built from source!

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.

[Ericson2314]

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.

[pauby]

I thought it was more directly competing with the likes of vcpkg, msys

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.

[Ericson2314]

@pauby I was already in the community chat, happy to discuss more there too.

Let's get the categorization straight:

• It seems like Chocolatey and WinGet are similar in both would prefer to ship upstream-provided binaries. This is emphatically not like apt, yum, dnf, brew etc., which want to build everything themselves.
• At the same time while vcpkg is only about building packages from source (only), they don't want to package executables (unless they are hard requirements to build further libraries).
• https://packages.msys2.org/packages/ is the only one that is like apt, yum, since those packages are (a) built from source, (b) free to be executables or libraries. However MSYS2 only does MinGW standard library (Clang or GCC), they don't do Clang in MSVC mode, or MSVC itself.

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?

[pauby]

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

[Ericson2314]

Nothing was redundant; I already joined the discord but didn't discuss things there yet.

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.

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.