compile packages from source

[Foadsf]

Copy and paste from here:

What:
Following the discussions with @gep13 here on Twitter and @pauby here I'm proposing to add compile from source feature:

choco install package --source

as also suggested here in this Scoop issue.

Why:

• there will be less need for binary hosting
• less maintenance for outdated formulas
• users will have access to the latest bug fixes and features in real time
• for those who want the optimized binaries
• incremental updates instead of downloading the whole binary

Other:
On MacOS HomeBrew can do this and on Linux guix/nix, Spack, EasyBuild, portage, pkgsrc, LinuxBrew ...

[ferventcoder]

tl;dr - I'm not saying we're against this, but currently we are not ready to approach this matter of complexity. I've yet to hear a compelling argument for this, but am open to ideas.

Two of the core tenants of Chocolatey are simplicity and security. Along with simplicity comes reliability and determinism. I will caveat that with the community repository can never be fully reliable due to distribution rights - and that the community repo only represents about 5% of Chocolatey packages in existence. Most packages used in organizations have binaries in the package. That's our recommendation for packages. So keep in mind there are different audiences that are users of Chocolatey.

• Simple: We want things to be simple on the user end and with the user experience. Adding in the build toolchain and downloading sources to build software requires a lot on a user machine. It's a lot more failure points to introduce into the process. Imagine if your parents or non-technical friends were installing something through the Chocolatey GUI. If the build failed somewhere in the process, what then? Sure, it sounds cool that you could have something build your tools on demand, but we don't do things just because we can. We prefer to have more deterministic approaches. We prefer the most compatibility.

If you've played in Ruby long enough, you've cursed Nokogiri (probably wasn't it's fault, it was probably a compiler incompatibility). If you've been in Ubuntu, it's likely you've applied a patch to a package due to an incompatibility on a newer version and the dpkg. Windows does not have incompatibilities across versions and only two architectures.

Having access to latest bug fixes and features in real time doesn't account for the fact that they may be getting a fix that is half-baked, not tested, or in progress. They may also be getting non-compiling code. Releases represent a point of support, a contract from a vendor/developer that this is ready. It gives folks something to point to and say this is broken and then fixes can come from that. It's not impossible to have those things, but you are asking more of the folks building tools to make sure things are always in a pristine state and that they have their versioning figured out for every build.

• Security: We want to have verified the binaries are safe. Checksums could be different if folks are using different build chains to build the software. Antivirus tools like VirusTotal look at a checksum to determine if this is the same software. It's more comforting to know what you are getting has been verified to likely not contain any malware (we know they are not perfect, but they are the best thing we have at the moment). Tool chains that build software at runtime sometimes trip antivirus tools, which might lock files and cause things to fail. They can result in different checksums with different compilers and compiler flags. This means less of that good feeling.
  Some users are not administrators, I'm not sure what requirements there are in bringing some of these toolsets.

Questions for you:

• Who are you optimizing for? Adding build time into the installation means you are increasing the installation time by quite a bit. If you've built with C++ compilers with optimizations, you already know it takes ages - that means increased install times by an order of magnitude. Our users are asking us to find ways to make things go faster, not slower. Why do that on EVERY machine instead of just one or two? Windows has very few architectures with a focus on compatibility across different versions / editions, so building everywhere seems really unnecessary.
• If a user wants to put in their own compiler flags, what happens when they use one that is incompatible? How do they give that bug report back to the software vendor? Seems like it reduces productivity overall. Folks that are going to explore better ways to build a project are those very familiar with the build chain and the software.
• Are users okay with having this approach or more comfortable with an approach of pre-built binaries that have been verified against 60-70 antivirus scanners?
• Did you ever consider why some POSIX environments tend to build from source as opposed to pre-built binaries?
• How does this feature make Chocolatey more or less approachable? From a packager perspective? Considering both system administrators and developers making packages?

What is the compelling reason that one should put a lot of focus into this? A developer that wants optimized binaries that thinks they know better than the developers that are building the tools are going to go build them themselves anyway, they are not likely to use tools they can't fully control. I'm fine with that.