Re: Update Hombrew install instructions on the web site

Thomas Leonard wrote:
>>> If you delete from opam-repository all the versions you're not using,
>>> it won't have any choice :-)
>>
>> Right, but if I just deleted the remote it didn't find anything at all.
>> Suppose I could do something with the repo, but it is too much hassle.
>
> Would this work?
>
>    export OPAMROOT=/tmp/opam
>    opam init --no-setup
>    opam remote remove default
>    tar cjf opam-empty.tar.bz2 /tmp/opam
>
> The small opam-empty.tar.bz2 could be added to the package. Then, at build-time:
>
>    opam remote add local /path/to/opam-repository
>    opam install 0install
>
> Might have to adjust the paths in "system/config/global-config.config"
> so they don't start /tmp/opam...

Well, I still don't understand. I removed the default remote,
and added the needed "ocamlfind" (again, thought it was default)
Couldn't find a way to init the opamroot without downloading
things like compilers, so downloaded it and threw it all away.

And now it hangs, starting an editor instead of doing something.
Apparently it wants to edit the name or version or whatever...
So the idea of staging each resource in a tempdir didn't work.
It seemed like it would, but the "opam" forgot the version ?

       resources.each do |r|
         r.stage { system "opam", "pin", "add", r.name, "." }
       end

==> opam pin add ocamlfind .
Package ocamlfind does not exist, create as a NEW package ? [Y/n] y
ocamlfind is now path-pinned to 
/tmp/zero-install--ocamlfind20150802-8137-xpan4y/ocamlfind.1.5.5

[ocamlfind: local]
[ocamlfind] 
/tmp/zero-install--ocamlfind20150802-8137-xpan4y/ocamlfind.1.5.5/ 
synchronized

And here it started up "nano" and just locked up the terminal. :-(
Apparently I could use some weird name.version syntax for package ?

But if there is no batch mode, and keeps messing with editors
and home directories and the network - it feels like wrong way...

Especially since the mktemp staging directories would be removed.


So it looks like there is no way to just "install" each package.

So the whole idea of "locally vendoring" the opam modules sounds
like it won't work. OPAM is too high-level, and too "easy-to-use".

And the whole artificial problem isn't worthy of solving anyway.


The two reasonable solutions is either to require (depends_on)
the modules, and the user uses opam. Or just use "opam install".

And since neither is "allowed" by the upstream, there just won't
be any binary package. Current build instructions will have to do.

--anders

------------------------------------------------------------------------------