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

> Hi Luke,
>
> On Fri, Jun 23, 2017 at 8:59 AM, Luke Gorrie <l...@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

Reply via email to