<div dir="ltr"><br><br>On Tue, Apr 18, 2017 at 4:13 AM, Luke Gorrie <<a href="mailto:luke@snabb.co">luke@snabb.co</a>> wrote:<br>><br>>  <br>> Hoi,<br>><br>> Just summarizing the "Pharo 6 snap install" thread from -users and -dev list,<br>><br>> I made a nix package for the latest (git master) Pharo VM with much help from the mailing list.<div><br></div><div>btw, just to clarify, the "master" branch of <a href="https://github.com/pharo-project/pharo-vm">https://github.com/pharo-project/pharo-vm</a></div><div>is synchronised to the "Cog" branch of <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm">https://github.com/OpenSmalltalk/opensmalltalk-vm</a></div><div><br></div><div>><br>> If you first install nix:<br>>     curl <a href="https://nixos.org/nix/install">https://nixos.org/nix/install</a> | sh<br>><br>> Then it's easy to install the package from my development branch:<br>>     nix-env -f <a href="https://github.com/lukego/nixpkgs/archive/pharo6.tar.gz">https://github.com/lukego/nixpkgs/archive/pharo6.tar.gz</a> -iA pkgs.pharo-vm<br>></div><div>> and then you can run it with pharo-vm-x (or pharo-vm-nox for headless.)<br><br></div><div><div>This worked fine for me on 32bit Debian 8 Jessie, resulting in...</div><div>  $ pharo-vm-x  -version</div></div><div>5.0-git.1c38b03fb043a2962f30f080db5b1292b5b7badb  Tue Apr 18 16:46:48 UTC 2017 gcc 6.3.0 [Production Spur VM]<br></div><div>CoInterpreter VMMaker.oscog-eem.2188 uuid: ff4ca601-cd05-4792-ab0d-dcdf19975239 Jan  1 1970</div><div>StackToRegisterMappingCogit VMMaker.oscog-eem.2188 uuid: ff4ca601-cd05-4792-ab0d-dcdf19975239 Jan  1 1970</div><div>VM: git.1c38b03fb043a2962f30f080db5b1292b5b7badb <a href="https://github.com/pharo-project/pharo-vm">https://github.com/pharo-project/pharo-vm</a> $ Date: Wed Apr 12 19:25:16 2017 +0200 $</div><div>Plugins:  </div><div>Linux dom0 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) i686 GNU/Linux</div><div>plugin path: /nix/store/w7hp77nli2khxvwp2dx3sbm6a3z4drlp-pharo-vm/lib/ [default: /nix/store/w7hp77nli2khxvwp2dx3sbm6a3z4drlp-pharo-vm/lib/]</div><div><br></div><div><br></div><div>><br>> Nix is a bit special. It will make a deep copy of all the dependencies including libcairo, glibc, etc. This means that it really should work the same on your computer as on mine, and it should also work the same if you run that command 5 years from now. (Like a cross between apt-get and docker.) The dependencies and be updated and debugged in a disciplined way (see example cute trick.)<br>> <a href="https://github.com/lukego/blog/issues/17">https://github.com/lukego/blog/issues/17</a><br><br>Thats quite amazing to be able to bisect the compiler tool chain dependencies across OS versions like that.  <br><br></div><div> <br>><br>><br>> Here is the source for the build script:<br>> <a href="https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/development/pharo/vm/build-vm.nix">https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/development/pharo/vm/build-vm.nix</a><div><br></div><div>How the parameters are provided is also interesting...</div><div><a href="https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/development/pharo/vm/default.nix">https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/development/pharo/vm/default.nix</a></div><div><br></div><div><br>><br>> This is based on the mvm script for Pharo. On the one hand it's simpler because nix takes care of all the third-party dependencies automatically, but on the other hand it's complicated because nix builds have to be referentially transparent and can't use curl, whoami, date, git, etc. There are also potentially many versions of each program installed on the machine and so you can't use global names like /bin/rm but rather have to rely on $PATH to give you the right one.<br>><br>> So I made some straightforward adaptations to accommodate nix, and also e.g. to avoid building with gcc5 which crashes during compilation.<br>><br>> My script is based on work by Damien Cassou who packaged an earlier version of the VM and has since moved on to other projects. I picked up the maintainership from him and will send this package to nix upstream once I test it a little better.<br><br><br>I had seen Damien mention nix before, but I didn't realise it covered reproducibility of the whole build environment so completely.<br> <br>><br>><br>> Why bother packaging the Pharo VM with nix? There are a few reasons for me. I already run NixOS and the Pharo binaries don't work there. Building from source takes more work than 'configure && make install' so it's worth automating. I'm not comfortable with the zeroconf installers because they feel opaque and I am never quite sure what software I am running on each machine. And I want to build a large application including Pharo + many other components and I need a tool to keep me out of dependency hell.<br></div><div><br></div><div><br>> More on Nix: gentle introduction<div>> <a href="https://www.infoq.com/articles/configuration-management-with-nix">https://www.infoq.com/articles/configuration-management-with-nix</a></div><div><br><div><div>This seems like useful tech for on-boarding new developers in a geographically dispersed team, "A Nix expression can serve as a declarative specification of all the dependencies that your project needs. Nix can then automatically build or download these dependencies in the exact versions required by your project, freeing developers from having to do this manually."  </div><div><br></div><div>Being able to try a compiler upgrade and then cleanly rollback is a great feature.  I gather that under the covers, so switching between two environments is just a quick link change? </div></div><div> </div></div><div>Having the package hash based on "the source code of the package and the build script, [and] also dependencies such as the C compiler and libraries against which [it] links (such as OpenSSL)" seems a really strong approach to configuration management and reproducibility of historical build environments.  As well as being great for production environments I could imagine a newcomer reporting "I'm having trouble building, here is my nix configuration" and an expert could use `nix-shell` to build within an identical environment to avoid the "works for me" phenomenon of hidden dependencies.  </div><div><br></div><div><div><br></div><div>> This is the best new technology that I have stumbled upon in the past couple of years.</div><div><br></div><div>The world turns.  Thanks for the heads up.  </div><div><br></div><div><br></div><div>Now would any of the other dialects like to add to this? </div><div>At a minimum, perhaps just adding sources filesto...</div><div><a href="https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/development/pharo/vm/share.nix">https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/development/pharo/vm/share.nix</a>  </div><div><br></div><div>cheers -ben</div><div><br><br></div></div></div></div></div>