<div dir="ltr"><div class="gmail_quote"><div dir="ltr">Hoi,<div><br></div><div>Just summarizing the "Pharo 6 snap install" thread from -users and -dev list,</div><div><br></div><div>I made a nix package for the latest (git master) Pharo VM with much help from the mailing list.</div><div><br></div><div>If you first install nix:<br><font face="monospace, monospace"><br></font></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="monospace, monospace">curl <a href="https://nixos.org/nix/install" target="_blank">https://nixos.org/nix/install</a> | sh</font></div></blockquote><div><br></div>Then it's easy to install the package from my development branch:<br><font face="monospace, monospace"><br></font><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="monospace, monospace">nix-env -f <a href="https://github.com/lukego/nixpkgs/archive/pharo6.tar.gz" target="_blank">https://github.com/lukego/<wbr>nixpkgs/archive/pharo6.tar.gz</a> -iA pkgs.pharo-vm</font></div></blockquote><div><div><br></div><div>and then you can run it with <font face="monospace, monospace">pharo-vm-x</font> (or <font face="monospace, monospace">pharo-vm-nox</font> for headless.)</div><div><br></div><div>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 <a href="https://github.com/lukego/blog/issues/17" target="_blank">cute trick</a>.)</div><div><br></div><div>Here is the source for the build script:</div><div><a href="https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/development/pharo/vm/build-vm.nix" target="_blank">https://github.com/lukego/<wbr>nixpkgs/blob/pharo6/pkgs/<wbr>development/pharo/vm/build-vm.<wbr>nix</a><br></div><div><br></div><div>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.</div><div><br></div><div>So I made some straightforward adaptations to accommodate nix, and also e.g. to avoid building with gcc5 which crashes during compilation.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Some open issues for me:</div></div><div><br></div><div>I'd like to be able to run the test suite, e.g. test runner for Pharo 6 image, and get a pass/fail result with no user interaction. I could have the nix upstream CI do this to check for breakages when dependencies are updated. Is there an easy way to do that? (How?)</div><div><br></div><div>I'd like to remove the warning asking for realtime scheduling at startup. I feel that cost/benefit is too high. The message is scary and it's the very first interaction with a new user. The instructions don't work on all distros e.g. not on NixOS. Playing with realtime scheduler priorities can have unintended consequences and has to be considered in context of the whole machine. I'd expect the default scheduler to provide decent latency with default settings e.g. ~10ms from event (?). So the benefits seem uncertain to me, but I don't want to do something that will degrade the user experience downstream and reflect badly on Pharo. I am open to words of caution. (I hate it when people package _my_ software and take artistic license.)</div><div><br></div><div>I have to think more about which VM variants to provide and how much magic to employ in choosing the right one when opening an image. Just now I am providing the 32-bit Spur VM by default and that seems to work with most images. I also have the 64-bit Spur VM as an option for people who specifically want to run 64-bit images. Do I need to provide more VMs? Which interesting Pharo images would I _not_ be able to run using the 32-bit Spur VM? Feedback would be welcome.</div><div><br></div><div>Have to think about whether to support MacOSX. Probably. I wrote support for it in the script but haven't tested it yet.</div><div><br></div><div>More on Nix: <a href="https://www.infoq.com/articles/configuration-management-with-nix" target="_blank">gentle introduction</a> and <a href="https://nixos.org/~eelco/pubs/phd-thesis.pdf" target="_blank">deep dive thesis</a>. This is the best new technology that I have stumbled upon in the past couple of years.</div><div><br></div><div>Cheers!</div><span class="HOEnZb"><font color="#888888"><div>-Luke</div><div><br></div><div><br></div></font></span></div>
</div><br></div>