On Sat, Jun 24, 2017 at 12:58 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Luke,

On Fri, Jun 23, 2017 at 8:59 AM, Luke Gorrie <luke@snabb.co> wrote:
Hi again Ben,

I have an idea for a hacky way to import all of the Pharo packages into my universe. Shooting holes in this idea would be welcome :).

Suppose that for each package "P" in the catalog I want to make a list of the recursive dependencies (mcz files) and their sha256 hashes. I would do this using a script that runs Pharo outside the sandbox and with access to the network:

- Start Pharo with an empty package cache.
- Download "P" and all of its dependencies automatically with Gofer.
- Inspect the package cache to see every mcz file that was downloaded and its sha256 hash.

btw, you may find interesting World > System > ��System Reporter > MC Working Copies��
which is coded at SystemReporter>>reportWorkingCopies:
��
Then I could use this process to bootstrap a package repository:

- Having a copy of all the .mcz files in a common ftp directory.
- Having a mapping of filename->sha256 to provide to nix.
- Having a mapping from package name ("P") to all .mcz dependencies.

This package repository could then be used for Nix such that I say which packages I want and it automatically downloads all of the required .mcz files, validates them with sha256 to make sure the build is reproducible, and then loads them all into an image and dumps the result ready for use.

So then on the Nix side I would write something like:

nix-build -E 'pharo6 { packages = [ roassal2 neojson ... ]; }'

and it would automatically create an image for me based on the package repository definition that it finds in Git.

Sane? Workable? Fatal flaws?

Workable?�� Yes.�� Fatal flaws?�� None.

Sane?�� Why introduce your own ftp directory?�� All you're doing is replicating all the repositories out there.�� Basically you want to seed a package-cache with any and all versions of the relevant packages.�� The ftp directory looks like a superfluous step.�� What you need to construct is the repository crawler that locates as many versions as you can find.�� The list of versions should be in each package; it's part of its history.�� You then have to find out where they are.�� As packages move from repository to repository (a sad fact of life) so tracking down these versions becomes difficult.

I guess its an attempt to shortcut that pain in five years when that Linux distribution wants to recreate a particular historical release. ��

cheers -ben