<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Thanks Ben for testing this, it's really helpful!</div><div class="gmail_quote"><br></div><div class="gmail_quote">On 20 April 2017 at 06:03, Ben Coman <span dir="ltr"><<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>After I did that and it spent a few minutes pulling in and compiling dependencies and compiling the VM,</div><div>I ran it again, and it completed immediately taking minimal action.  Thats cool! </div></div></div></div></blockquote><div><br></div><div>This is the nice benefit of referential transparency on the builds. Since the result is always the same, because the whole build environment is held constant, you can safely reuse previous builds instead of making new ones. Your /nix/store directory contains all the builds you have made. (You can run 'nix-collect-garbage' to free up space from old builds.)</div><div><br></div><div>Once the packages go upstream nobody will need to compile it locally. Their 'nix-env' command will use the sha256 to get a binary from <a href="http://cache.nixos.org">cache.nixos.org</a> (populated by upstream CI builds.)</div><div><br></div><div>But yeah the first time it sure takes a while because you are basically downloading a whole Linux distro. I neglected to mention that you could write 'nix-env -j 10' to run many build steps (including downloads) in parallel. That can really speed things up at the expense of obfuscating the output.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>When I ran that, it kicked off a few more minutes compiling.  Is that expected?<br></div></div></div></div></blockquote><div><br></div><div>Installing the first image will also install Xvfb (+ dependencies) in order to run a unit test. (Could be that I should run headless pharo instead but figured that exercising the X11 display driver would be worth the extra installation time.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Also I got an error "error: detected 64-bit image but 64-bit VM is not available"</div><div>perhaps since I'm on 32-bit Debian (Jessie-8).  Is there some way to guard against such error?</div></div></div></div></blockquote><div><br></div><div>Good catch!</div><div><br></div><div>This error is from installing a 64-bit Pharo image. The unit test will check that the image actually runs, and this failed due to missing the required VM.</div><div><br></div><div>The solution is that I need to exclude the 64-bit images on 32-bit machines. (I did already exclude the spur64 VM but I didn't think to exclude the images too.)</div><div><br></div><div>Just as a workaround you could install images individually by changing '-iA pharo' to e.g. '-iA pharo5' or '-iA moose61'.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Since Pharo 6 is not yet released, what are the implications of naming these pharo-6.dev <br></div></div></div></div></blockquote><div><br></div><div>On reflection I will split up my packaging work into "vm" and "image" components. I will send the vm upstream ASAP. I will leave the images on a development branch, perhaps indefinitely, because I am not sure that I am on the right track there at all.</div><div><br></div><div>So, here are more thoughts on image packaging, but with the disclaimer that I will probably not actively pursue this topic further at the moment:</div><div><br></div><div>I assert that Pharo 5 and Pharo 6 are both released, and are both fast-moving targets.</div><div><br></div><div>On <a href="http://pharo.org/download">http://pharo.org/download</a> there is a prominent link to Pharo 6 as the "development version" ready for download. Anecdotally the Pharo community that I interact with (mailing list, twitter, slack chat, etc) seem more focused on Pharo 6 than on Pharo 5. Occasionally people express surprise when I tell them I am "still" using Pharo 5.</div><div><br></div><div>On <a href="http://files.pharo.org/image/50/">http://files.pharo.org/image/50/</a> there is a new release of Pharo 5 every few weeks. This means that each time I have downloaded "Pharo 5" in the past I have probably gotten a different image and a different VM. So from my end-user perspective I have no idea what software I am installing regardless of whether I choose Pharo 5 or Pharo 6.</div><div><br></div><div>So as a nix user it would make sense for me to be able to download both Pharo 5 and Pharo 6 and for the nix package definitions to determine exactly which software I am running (as opposed to getting an invisible update from Pharo upstream every few days/weeks potentially leading to "but it worked fine on my other machine..." sorts of problems that are exactly what can nix protect me from.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Packing the other images is maybe also wrong.  How would you deal with user state being stored in the image when a new build download in available?</div></div></div></div></blockquote><div><br></div><div>The ad-hoc idea that I ran with is this:</div><div><br></div><div>Running a script like pharo-5.0 (or moose-6.1, etc) will make a temporary copy of the image in the current directory. The changes file will be read-write (requirement) but the image file will be read-only. The model is "you saved it, you own it" i.e. if you want the image to survive after exit you need to "Save image as..." and once you do that then you are responsible for it.</div><div><br></div><div>Code: <a href="https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/development/pharo/images/build-image.nix#L27-L33">script to run an image</a> and <a href="https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/development/pharo/wrapper/pharo-vm.sh">script to start the right vm</a>.</div><div><br></div><div>I am not sure why "Save image as..." is misbehaving for me. I have tested every combination of read/write permissions on the working directory, the image, the changes file, etc, but it was always the same. I am sure that I can work this out via the Smalltalk debugger -- but at the moment it seems to make more sense to focus on the VM than on the images. (I want to wrap this up.)</div><div><br></div><div>The downside to skipping the images is that I don't maintain feature parity with Damien's original nix packaging. He packaged the launcher image and then that was the gateway to everything else. This solution doesn't feel very solid to me, since now in 2017 I don't think the launcher is accounting for all the different VM requirements properly, but I am not willing to pick up maintenance of that image so that is life.</div><div><br></div><div>Cheers,</div><div>-Luke</div><div><br></div><div><br></div></div></div></div>