[Caml-list] [ANN] beta-release of OPAM

[Caml-list] [ANN] beta-release of OPAM

[Thomas Gazagnaire]

I'm very happy to announce the beta release of OPAM (0.9.1). OPAM is a package manager for OCaml to install libraries and tools from source archives. It supports multiple simultaneous compiler installations, flexible package constraints, and a Git-friendly development workflow.

The goal of this beta release is to formally introduce OPAM to the community, to gather some general feedback on the documentation and tools and double-check that we've not forgotten some useful features. I would also like to use that opportunity to make an official call to maintainers: if you have developed packages which are already in OPAM do not hesitate to claim their ownership and to improve their description - if your packages are not yet in, it's time to start packaging them! 

OPAM is developed by OCamlPro[1] and has been in alpha release since June 2012. It is already quite mature and has gained some nice momentum (+40 contributors, +300 packages).  OPAM has been initially funded by Jane Street[2] and the DORM EU research project, and it has received continuous help and resources from OCamlLabs[3].

The source code of OPAM is available on Github:
* installer: https://github.com/OCamlpro/opam
* packages and compiler descriptions: https://github.com/OCamlPro/opam-repository
* website: https://github.com/OCamlPro/opam2web

The documention:
* install instructions and tutorial are available http://opam.ocamlpro.com/
* the main source of documentation is 'opam --help' or 'opam <command> --help'
* user manual: https://github.com/OCamlPro/opam/raw/master/doc/dev-manual/dev-manual.pdf

You can report issues on github bug tracker:
* https://github.com/OCamlPro/opam/issues

The next steps for us is to focus on improving the package descriptions quality and the global consistency of https://github.com/OCamlPro/opam-repository. We will gladly accept any kind of help and support from the community to do this!  We plan to announce the release of 1.0.0 in a couple of months, with improved package quality and better integration with the future OCaml platform.

Last point, if you are working in a company and that you already use OPAM, or plan to use OPAM, and you would like to help us ensuring it a sustainable future[2], you can contact us at contact@ocamlpro.com. 

On behalf of the OPAM team,
Thomas Gazagnaire

[1] http://www.ocamlpro.com/
[2] http://www.janestreet.com/
[3] http://www.cl.cam.ac.uk/projects/ocamllabs/

[Caml-list] Re: [ANN] beta-release of OPAM

[Anil Madhavapeddy]

If you're using Homebrew on the Mac, just do a "brew update" and you should get the latest beta release (0.9.1) via it.  Enjoy!

-anil

On 15 Jan 2013, at 15:40, Thomas Gazagnaire <thomas@ocamlpro.com> wrote:

> I'm very happy to announce the beta release of OPAM (0.9.1). OPAM is a package manager for OCaml to install libraries and tools from source archives. It supports multiple simultaneous compiler installations, flexible package constraints, and a Git-friendly development workflow.
> 
> The goal of this beta release is to formally introduce OPAM to the community, to gather some general feedback on the documentation and tools and double-check that we've not forgotten some useful features. I would also like to use that opportunity to make an official call to maintainers: if you have developed packages which are already in OPAM do not hesitate to claim their ownership and to improve their description - if your packages are not yet in, it's time to start packaging them! 
> 
> OPAM is developed by OCamlPro[1] and has been in alpha release since June 2012. It is already quite mature and has gained some nice momentum (+40 contributors, +300 packages).  OPAM has been initially funded by Jane Street[2] and the DORM EU research project, and it has received continuous help and resources from OCamlLabs[3].
> 
> The source code of OPAM is available on Github:
> * installer: https://github.com/OCamlpro/opam
> * packages and compiler descriptions: https://github.com/OCamlPro/opam-repository
> * website: https://github.com/OCamlPro/opam2web
> 
> The documention:
> * install instructions and tutorial are available http://opam.ocamlpro.com/
> * the main source of documentation is 'opam --help' or 'opam <command> --help'
> * user manual: https://github.com/OCamlPro/opam/raw/master/doc/dev-manual/dev-manual.pdf
> 
> You can report issues on github bug tracker:
> * https://github.com/OCamlPro/opam/issues
> 
> The next steps for us is to focus on improving the package descriptions quality and the global consistency of https://github.com/OCamlPro/opam-repository. We will gladly accept any kind of help and support from the community to do this!  We plan to announce the release of 1.0.0 in a couple of months, with improved package quality and better integration with the future OCaml platform.
> 
> Last point, if you are working in a company and that you already use OPAM, or plan to use OPAM, and you would like to help us ensuring it a sustainable future[2], you can contact us at contact@ocamlpro.com. 
> 
> On behalf of the OPAM team,
> Thomas Gazagnaire
> 
> [1] http://www.ocamlpro.com/
> [2] http://www.janestreet.com/
> [3] http://www.cl.cam.ac.uk/projects/ocamllabs/
> 
> 
> 

[Caml-list] Re: [ANN] beta-release of OPAM

[Thomas Gazagnaire]

To people already using OPAM, I forgot to mention that it is highly recommended to NOT upgrade opam using opam. The auto-update thing was a mistake at the first place. It is also advised to start from a fresh opam init. It should work if you don't, but it would definitely avoid some confusions in some corner-cases.

--
Thomas



On Jan 15, 2013, at 3:42 PM, Anil Madhavapeddy wrote:

> If you're using Homebrew on the Mac, just do a "brew update" and you should get the latest beta release (0.9.1) via it.  Enjoy!
> 
> -anil
> 
> On 15 Jan 2013, at 15:40, Thomas Gazagnaire <thomas@ocamlpro.com> wrote:
> 
>> I'm very happy to announce the beta release of OPAM (0.9.1). OPAM is a package manager for OCaml to install libraries and tools from source archives. It supports multiple simultaneous compiler installations, flexible package constraints, and a Git-friendly development workflow.
>> 
>> The goal of this beta release is to formally introduce OPAM to the community, to gather some general feedback on the documentation and tools and double-check that we've not forgotten some useful features. I would also like to use that opportunity to make an official call to maintainers: if you have developed packages which are already in OPAM do not hesitate to claim their ownership and to improve their description - if your packages are not yet in, it's time to start packaging them! 
>> 
>> OPAM is developed by OCamlPro[1] and has been in alpha release since June 2012. It is already quite mature and has gained some nice momentum (+40 contributors, +300 packages).  OPAM has been initially funded by Jane Street[2] and the DORM EU research project, and it has received continuous help and resources from OCamlLabs[3].
>> 
>> The source code of OPAM is available on Github:
>> * installer: https://github.com/OCamlpro/opam
>> * packages and compiler descriptions: https://github.com/OCamlPro/opam-repository
>> * website: https://github.com/OCamlPro/opam2web
>> 
>> The documention:
>> * install instructions and tutorial are available http://opam.ocamlpro.com/
>> * the main source of documentation is 'opam --help' or 'opam <command> --help'
>> * user manual: https://github.com/OCamlPro/opam/raw/master/doc/dev-manual/dev-manual.pdf
>> 
>> You can report issues on github bug tracker:
>> * https://github.com/OCamlPro/opam/issues
>> 
>> The next steps for us is to focus on improving the package descriptions quality and the global consistency of https://github.com/OCamlPro/opam-repository. We will gladly accept any kind of help and support from the community to do this!  We plan to announce the release of 1.0.0 in a couple of months, with improved package quality and better integration with the future OCaml platform.
>> 
>> Last point, if you are working in a company and that you already use OPAM, or plan to use OPAM, and you would like to help us ensuring it a sustainable future[2], you can contact us at contact@ocamlpro.com. 
>> 
>> On behalf of the OPAM team,
>> Thomas Gazagnaire
>> 
>> [1] http://www.ocamlpro.com/
>> [2] http://www.janestreet.com/
>> [3] http://www.cl.cam.ac.uk/projects/ocamllabs/
>> 
>> 
>> 
> 

Re: [Caml-list] [ANN] beta-release of OPAM

[Daniel Bünzli]

Le mardi, 15 janvier 2013 à 16:40, Thomas Gazagnaire a écrit :
> if you have developed packages which are already in OPAM do not hesitate to claim their ownership and to improve their description - if your packages are not yet in, it's time to start packaging them!

At a certain point I plan to do so. Is there, however, any known tool/scripts that can help me to streamline this process via the _oasis file of my packages ? This file already contains ammost everything: a package name, version, synopsis, description and (implicit) build instructions (see [1] for an example).

Also the problem of package documentation/sample code seems side stepped at the moment. Are there any future plans with respect to that ?  
  
Thanks for the tool,

Daniel

[1] http://erratique.ch/repos/jsonm/tree/_oasis?id=v0.9.1

Re: [Caml-list] Re: [ANN] beta-release of OPAM

[Alan Schmitt]

Thomas Gazagnaire writes:

> To people already using OPAM, I forgot to mention that it is highly
> recommended to NOT upgrade opam using opam. The auto-update thing was
> a mistake at the first place. It is also advised to start from a fresh
> opam init. It should work if you don't, but it would definitely avoid
> some confusions in some corner-cases.

I'm thinking of trying it, but there was a bit of information I could
not find on the web page: where does OPAM puts the things it compiles?
Is it easy to just try it with an existing installation of ocaml &
libraries?

Thanks,

Alan

Re: [Caml-list] Re: [ANN] beta-release of OPAM

[Fabrice Le Fessant]

OPAM installs everything in ~/.opam by default, so it won't pollute
your current installation of OCaml. You have to use:

eval `opam config -env`

in a terminal to start using the version of OCaml installed by OPAM
(you can put that in a .bashrc file, for example).

--Fabrice

On Tue, Jan 15, 2013 at 8:18 PM, Alan Schmitt
<alan.schmitt@polytechnique.org> wrote:
> Thomas Gazagnaire writes:
>
>> To people already using OPAM, I forgot to mention that it is highly
>> recommended to NOT upgrade opam using opam. The auto-update thing was
>> a mistake at the first place. It is also advised to start from a fresh
>> opam init. It should work if you don't, but it would definitely avoid
>> some confusions in some corner-cases.
>
> I'm thinking of trying it, but there was a bit of information I could
> not find on the web page: where does OPAM puts the things it compiles?
> Is it easy to just try it with an existing installation of ocaml &
> libraries?
>
> Thanks,
>
> Alan
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs



-- 
Fabrice LE FESSANT

Re: [Caml-list] Re: [ANN] beta-release of OPAM

[Anil Madhavapeddy]

There is just one odd corner case that I've been trying to track down.

If you have ocamlfind installed in your system PATH, then the 
"ocamlbuild -use-ocamlfind" mode seems to pick that one up in preference
to the OPAM-installed ocamlfind (which sits in ~/.opam/<compiler>/bin, and
is also on the PATH).

I've not fixed that yet, but if you do run into odd bugs where an OPAM 
package fails to build due to not finding a library, then try uninstalling
your system findlib, and the OPAM one should be picked up.

This doesn't happen with OASIS ocamlfind invocations, but only with the
-use-ocamlfind mode of ocamlbuild.

-anil

On 15 Jan 2013, at 19:25, Fabrice Le Fessant <fabrice@lefessant.net> wrote:

> OPAM installs everything in ~/.opam by default, so it won't pollute
> your current installation of OCaml. You have to use:
> 
> eval `opam config -env`
> 
> in a terminal to start using the version of OCaml installed by OPAM
> (you can put that in a .bashrc file, for example).
> 
> --Fabrice
> 
> On Tue, Jan 15, 2013 at 8:18 PM, Alan Schmitt
> <alan.schmitt@polytechnique.org> wrote:
>> Thomas Gazagnaire writes:
>> 
>>> To people already using OPAM, I forgot to mention that it is highly
>>> recommended to NOT upgrade opam using opam. The auto-update thing was
>>> a mistake at the first place. It is also advised to start from a fresh
>>> opam init. It should work if you don't, but it would definitely avoid
>>> some confusions in some corner-cases.
>> 
>> I'm thinking of trying it, but there was a bit of information I could
>> not find on the web page: where does OPAM puts the things it compiles?
>> Is it easy to just try it with an existing installation of ocaml &
>> libraries?
>> 
>> Thanks,
>> 
>> Alan
>> 
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 
> 
> 
> -- 
> Fabrice LE FESSANT
> 

Re: [Caml-list] Re: [ANN] beta-release of OPAM

[Roberto Di Cosmo]

I can confirm this : on opam 0.8.3, this bug prevented me from
compiling properly a test code for Parmap.
It definitely needs to be fixed :-)

On Tue, Jan 15, 2013 at 07:29:56PM +0000, Anil Madhavapeddy wrote:
> There is just one odd corner case that I've been trying to track down.
> 
> If you have ocamlfind installed in your system PATH, then the 
> "ocamlbuild -use-ocamlfind" mode seems to pick that one up in preference
> to the OPAM-installed ocamlfind (which sits in ~/.opam/<compiler>/bin, and
> is also on the PATH).
> 
> I've not fixed that yet, but if you do run into odd bugs where an OPAM 
> package fails to build due to not finding a library, then try uninstalling
> your system findlib, and the OPAM one should be picked up.
> 
> This doesn't happen with OASIS ocamlfind invocations, but only with the
> -use-ocamlfind mode of ocamlbuild.
> 
> -anil
> 
> On 15 Jan 2013, at 19:25, Fabrice Le Fessant <fabrice@lefessant.net> wrote:
> 
> > OPAM installs everything in ~/.opam by default, so it won't pollute
> > your current installation of OCaml. You have to use:
> > 
> > eval `opam config -env`
> > 
> > in a terminal to start using the version of OCaml installed by OPAM
> > (you can put that in a .bashrc file, for example).
> > 
> > --Fabrice
> > 
> > On Tue, Jan 15, 2013 at 8:18 PM, Alan Schmitt
> > <alan.schmitt@polytechnique.org> wrote:
> >> Thomas Gazagnaire writes:
> >> 
> >>> To people already using OPAM, I forgot to mention that it is highly
> >>> recommended to NOT upgrade opam using opam. The auto-update thing was
> >>> a mistake at the first place. It is also advised to start from a fresh
> >>> opam init. It should work if you don't, but it would definitely avoid
> >>> some confusions in some corner-cases.
> >> 
> >> I'm thinking of trying it, but there was a bit of information I could
> >> not find on the web page: where does OPAM puts the things it compiles?
> >> Is it easy to just try it with an existing installation of ocaml &
> >> libraries?
> >> 
> >> Thanks,
> >> 
> >> Alan
> >> 
> >> --
> >> Caml-list mailing list.  Subscription management and archives:
> >> https://sympa.inria.fr/sympa/arc/caml-list
> >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> >> Bug reports: http://caml.inria.fr/bin/caml-bugs
> > 
> > 
> > 
> > -- 
> > Fabrice LE FESSANT
> > 
> 
> 
> -- 
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

-- 
Roberto Di Cosmo
 
------------------------------------------------------------------
Professeur               En delegation a l'INRIA
PPS                      E-mail: roberto@dicosmo.org
Universite Paris Diderot WWW  : http://www.dicosmo.org
Case 7014                Tel  : ++33-(0)1-57 27 92 20
5, Rue Thomas Mann       
F-75205 Paris Cedex 13   Identica: http://identi.ca/rdicosmo
FRANCE.                  Twitter: http://twitter.com/rdicosmo
------------------------------------------------------------------
Attachments:
MIME accepted, Word deprecated
      http://www.gnu.org/philosophy/no-word-attachments.html
------------------------------------------------------------------
Office location:
 
Bureau 6C08 (6th floor)
175, rue du Chevaleret, XIII
Metro Chevaleret, ligne 6
-----------------------------------------------------------------
GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3                        

Re: [Caml-list] Re: [ANN] beta-release of OPAM

[Daniel Bünzli]

Le mardi, 15 janvier 2013 à 17:17, Thomas Gazagnaire a écrit :
> To people already using OPAM, I forgot to mention that it is highly recommended to NOT upgrade opam using opam. The auto-update thing was a mistake at the first place. It is also advised to start from a fresh opam init. It should work if you don't, but it would definitely avoid some confusions in some corner-cases.

But we agree there's no problem in compiling the new opam binary with an opam install remove ~/.opam and then restart with a fresh init with the new binary ?  

Best,

Daniel

Re: [Caml-list] Re: [ANN] beta-release of OPAM

[Wojciech Meyer]

Roberto Di Cosmo <roberto@dicosmo.org> writes:

> I can confirm this : on opam 0.8.3, this bug prevented me from
> compiling properly a test code for Parmap.
> It definitely needs to be fixed :-)

It's been fixed on trunk now.

Thanks for reporting,

--
Wojciech Meyer
http://danmey.org

Re: [Caml-list] Re: [ANN] beta-release of OPAM

[Thomas Gazagnaire]

>> To people already using OPAM, I forgot to mention that it is highly recommended to NOT upgrade opam using opam. The auto-update thing was a mistake at the first place. It is also advised to start from a fresh opam init. It should work if you don't, but it would definitely avoid some confusions in some corner-cases.
> 
> But we agree there's no problem in compiling the new opam binary with an opam install remove ~/.opam and then restart with a fresh init with the new binary ?  

The issue with 'opam update opam' is that this installs the opam binary in ~/.opam/<switch>/bin. If you manually move the new opam to a safe place (say in /usr/local/bin) before removing ~/.opam, yes that should be fine.

--
Thomas

Re: [Caml-list] [ANN] beta-release of OPAM

[Anil Madhavapeddy]

On 15 Jan 2013, at 21:12, Wojciech Meyer <wojciech.meyer@gmail.com> wrote:

> Roberto Di Cosmo <roberto@dicosmo.org> writes:
> 
>> I can confirm this : on opam 0.8.3, this bug prevented me from
>> compiling properly a test code for Parmap.
>> It definitely needs to be fixed :-)
> 
> It's been fixed on trunk now.

Thanks for the quick fix!  Looking at the patch, the problem
seems to be that ocamlbuild distinguishes between built-in tools
(presumably the ocaml toolchain binaries), and external tools.

Is there any reason why ocamlbuild shouldn't just unconditionally
search the PATH for the compiler tools as well?  It's very confusing
to have it override some binaries and not others.

-anil

Re: [Caml-list] [ANN] beta-release of OPAM

[Wojciech Meyer]

On Wed, Jan 16, 2013 at 10:01 AM, Anil Madhavapeddy <anil@recoil.org> wrote:
> Thanks for the quick fix!  Looking at the patch, the problem
> seems to be that ocamlbuild distinguishes between built-in tools
> (presumably the ocaml toolchain binaries), and external tools.
>
> Is there any reason why ocamlbuild shouldn't just unconditionally
> search the PATH for the compiler tools as well?  It's very confusing
> to have it override some binaries and not others.

Yes, this area appears to me a bit hairy and over engineered. I see no
real benefit of having such complex logic there too instead of using
just PATH, but let me figure out if we can do it.
However, I'm sure these changes must be there for some reason, I will
ping Nicolas with the query today.

-Wojciech

Re: [Caml-list] [ANN] beta-release of OPAM

[Gabriel Scherer]

I suppose that the tool may want to use a different way of finding the
OCaml executables during the OCaml, then ocamlbuild, bootstrap
process.

On Wed, Jan 16, 2013 at 11:08 AM, Wojciech Meyer
<wojciech.meyer@gmail.com> wrote:
> On Wed, Jan 16, 2013 at 10:01 AM, Anil Madhavapeddy <anil@recoil.org> wrote:
>> Thanks for the quick fix!  Looking at the patch, the problem
>> seems to be that ocamlbuild distinguishes between built-in tools
>> (presumably the ocaml toolchain binaries), and external tools.
>>
>> Is there any reason why ocamlbuild shouldn't just unconditionally
>> search the PATH for the compiler tools as well?  It's very confusing
>> to have it override some binaries and not others.
>
> Yes, this area appears to me a bit hairy and over engineered. I see no
> real benefit of having such complex logic there too instead of using
> just PATH, but let me figure out if we can do it.
> However, I'm sure these changes must be there for some reason, I will
> ping Nicolas with the query today.
>
> -Wojciech
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] [ANN] beta-release of OPAM

[Wojciech Meyer]

Then during the bootstrap process we should be probably specifing
explicitly the tool via command line, not relying on a fragile path
resolution.
The plan is however is to stop bootstrapping ocamlbuild at some point
soon as it brings minimal benefit for the cost of the very complicated
scripts.

On Wed, Jan 16, 2013 at 12:13 PM, Gabriel Scherer
<gabriel.scherer@gmail.com> wrote:
> I suppose that the tool may want to use a different way of finding the
> OCaml executables during the OCaml, then ocamlbuild, bootstrap
> process.
>
> On Wed, Jan 16, 2013 at 11:08 AM, Wojciech Meyer
> <wojciech.meyer@gmail.com> wrote:
>> On Wed, Jan 16, 2013 at 10:01 AM, Anil Madhavapeddy <anil@recoil.org> wrote:
>>> Thanks for the quick fix!  Looking at the patch, the problem
>>> seems to be that ocamlbuild distinguishes between built-in tools
>>> (presumably the ocaml toolchain binaries), and external tools.
>>>
>>> Is there any reason why ocamlbuild shouldn't just unconditionally
>>> search the PATH for the compiler tools as well?  It's very confusing
>>> to have it override some binaries and not others.
>>
>> Yes, this area appears to me a bit hairy and over engineered. I see no
>> real benefit of having such complex logic there too instead of using
>> just PATH, but let me figure out if we can do it.
>> However, I'm sure these changes must be there for some reason, I will
>> ping Nicolas with the query today.
>>
>> -Wojciech
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] [ANN] beta-release of OPAM

[Gabriel Scherer]

I'm fine with whatever solution you'll devise.

Let me take this occasion to thank you publicly for the numerous
contribution you've brought to OCamlbuild in the last few months.
We've not yet succeeded in encouraging other people to contribute
(dear user: you should!), but fixing those little edge cases is very
helpful.

On Wed, Jan 16, 2013 at 3:43 PM, Wojciech Meyer
<wojciech.meyer@gmail.com> wrote:
> Then during the bootstrap process we should be probably specifing
> explicitly the tool via command line, not relying on a fragile path
> resolution.
> The plan is however is to stop bootstrapping ocamlbuild at some point
> soon as it brings minimal benefit for the cost of the very complicated
> scripts.
>
> On Wed, Jan 16, 2013 at 12:13 PM, Gabriel Scherer
> <gabriel.scherer@gmail.com> wrote:
>> I suppose that the tool may want to use a different way of finding the
>> OCaml executables during the OCaml, then ocamlbuild, bootstrap
>> process.
>>
>> On Wed, Jan 16, 2013 at 11:08 AM, Wojciech Meyer
>> <wojciech.meyer@gmail.com> wrote:
>>> On Wed, Jan 16, 2013 at 10:01 AM, Anil Madhavapeddy <anil@recoil.org> wrote:
>>>> Thanks for the quick fix!  Looking at the patch, the problem
>>>> seems to be that ocamlbuild distinguishes between built-in tools
>>>> (presumably the ocaml toolchain binaries), and external tools.
>>>>
>>>> Is there any reason why ocamlbuild shouldn't just unconditionally
>>>> search the PATH for the compiler tools as well?  It's very confusing
>>>> to have it override some binaries and not others.
>>>
>>> Yes, this area appears to me a bit hairy and over engineered. I see no
>>> real benefit of having such complex logic there too instead of using
>>> just PATH, but let me figure out if we can do it.
>>> However, I'm sure these changes must be there for some reason, I will
>>> ping Nicolas with the query today.
>>>
>>> -Wojciech
>>>
>>> --
>>> Caml-list mailing list.  Subscription management and archives:
>>> https://sympa.inria.fr/sympa/arc/caml-list
>>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] [ANN] beta-release of OPAM

[Mike Lin]

Congratulations to everyone involved, and thanks. OPAM is a pleasure
to use, and packaging could hardly be easier. Mike

On Tue, Jan 15, 2013 at 7:40 AM, Thomas Gazagnaire <thomas@ocamlpro.com> wrote:
> I'm very happy to announce the beta release of OPAM (0.9.1). OPAM is a package manager for OCaml to install libraries and tools from source archives. It supports multiple simultaneous compiler installations, flexible package constraints, and a Git-friendly development workflow.
>
> The goal of this beta release is to formally introduce OPAM to the community, to gather some general feedback on the documentation and tools and double-check that we've not forgotten some useful features. I would also like to use that opportunity to make an official call to maintainers: if you have developed packages which are already in OPAM do not hesitate to claim their ownership and to improve their description - if your packages are not yet in, it's time to start packaging them!
>
> OPAM is developed by OCamlPro[1] and has been in alpha release since June 2012. It is already quite mature and has gained some nice momentum (+40 contributors, +300 packages).  OPAM has been initially funded by Jane Street[2] and the DORM EU research project, and it has received continuous help and resources from OCamlLabs[3].
>
> The source code of OPAM is available on Github:
> * installer: https://github.com/OCamlpro/opam
> * packages and compiler descriptions: https://github.com/OCamlPro/opam-repository
> * website: https://github.com/OCamlPro/opam2web
>
> The documention:
> * install instructions and tutorial are available http://opam.ocamlpro.com/
> * the main source of documentation is 'opam --help' or 'opam <command> --help'
> * user manual: https://github.com/OCamlPro/opam/raw/master/doc/dev-manual/dev-manual.pdf
>
> You can report issues on github bug tracker:
> * https://github.com/OCamlPro/opam/issues
>
> The next steps for us is to focus on improving the package descriptions quality and the global consistency of https://github.com/OCamlPro/opam-repository. We will gladly accept any kind of help and support from the community to do this!  We plan to announce the release of 1.0.0 in a couple of months, with improved package quality and better integration with the future OCaml platform.
>
> Last point, if you are working in a company and that you already use OPAM, or plan to use OPAM, and you would like to help us ensuring it a sustainable future[2], you can contact us at contact@ocamlpro.com.
>
> On behalf of the OPAM team,
> Thomas Gazagnaire
>
> [1] http://www.ocamlpro.com/
> [2] http://www.janestreet.com/
> [3] http://www.cl.cam.ac.uk/projects/ocamllabs/
>
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] [ANN] beta-release of OPAM

[Fabrice Le Fessant]

I would suggest that OPAM should always set the variable OCAMLFIND_CONF 
to $HOME/.opam/$COMPILER/lib/findlib.conf, so that, whatever the 
"ocamlfind" that ocamlbuild uses, it will always use the packages 
installed by OPAM.

Can't this be automatically done by defining the variable in the .opam 
of ocamlfind ?

--Fabrice

On 01/16/2013 11:01 AM, Anil Madhavapeddy wrote:
> On 15 Jan 2013, at 21:12, Wojciech Meyer <wojciech.meyer@gmail.com> wrote:
>
>> Roberto Di Cosmo <roberto@dicosmo.org> writes:
>>
>>> I can confirm this : on opam 0.8.3, this bug prevented me from
>>> compiling properly a test code for Parmap.
>>> It definitely needs to be fixed :-)
>>
>> It's been fixed on trunk now.
>
> Thanks for the quick fix!  Looking at the patch, the problem
> seems to be that ocamlbuild distinguishes between built-in tools
> (presumably the ocaml toolchain binaries), and external tools.
>
> Is there any reason why ocamlbuild shouldn't just unconditionally
> search the PATH for the compiler tools as well?  It's very confusing
> to have it override some binaries and not others.
>
> -anil
>

Re: [Caml-list] [ANN] beta-release of OPAM

[Daniel Bünzli]

Le mercredi, 16 janvier 2013 à 17:54, Mike Lin a écrit :
> Congratulations to everyone involved, and thanks. OPAM is a pleasure
> to use, and packaging could hardly be easier. Mike

Agreed, the other day I had to make a local repository with the latest version of uucd to make a new release of uunf. It was so easy, quick and flawless to do it that I can hardly remember how I did it.  

Best,

Daniel

Re: [Caml-list] [ANN] beta-release of OPAM

[Thomas Gazagnaire]

> I would suggest that OPAM should always set the variable OCAMLFIND_CONF to $HOME/.opam/$COMPILER/lib/findlib.conf, so that, whatever the "ocamlfind" that ocamlbuild uses, it will always use the packages installed by OPAM.

I've tried that and unfortunately this didn't seem to work. ocamlfind is picking the wrong compiler.

--
Thomas

> 
> Can't this be automatically done by defining the variable in the .opam of ocamlfind ?
> 
> --Fabrice
> 
> On 01/16/2013 11:01 AM, Anil Madhavapeddy wrote:
>> On 15 Jan 2013, at 21:12, Wojciech Meyer <wojciech.meyer@gmail.com> wrote:
>> 
>>> Roberto Di Cosmo <roberto@dicosmo.org> writes:
>>> 
>>>> I can confirm this : on opam 0.8.3, this bug prevented me from
>>>> compiling properly a test code for Parmap.
>>>> It definitely needs to be fixed :-)
>>> 
>>> It's been fixed on trunk now.
>> 
>> Thanks for the quick fix!  Looking at the patch, the problem
>> seems to be that ocamlbuild distinguishes between built-in tools
>> (presumably the ocaml toolchain binaries), and external tools.
>> 
>> Is there any reason why ocamlbuild shouldn't just unconditionally
>> search the PATH for the compiler tools as well?  It's very confusing
>> to have it override some binaries and not others.
>> 
>> -anil
>> 
> 

Re: [Caml-list] [ANN] beta-release of OPAM

[Fabrice Le Fessant]

On 01/16/2013 06:40 PM, Thomas Gazagnaire wrote:
>> I would suggest that OPAM should always set the variable OCAMLFIND_CONF to $HOME/.opam/$COMPILER/lib/findlib.conf, so that, whatever the "ocamlfind" that ocamlbuild uses, it will always use the packages installed by OPAM.
>
> I've tried that and unfortunately this didn't seem to work. ocamlfind is picking the wrong compiler.

We just tried it with Roberto, and it worked.

--Fabrice

Re: [Caml-list] [ANN] beta-release of OPAM

[Roberto Di Cosmo]

Hmm... these two assertions are not necessarily contradictory:

 - on my test virtual machine, ocamlfind did not find the packages
   installed with opam, and this did the trick (thanks Fabrice!)

 - but I only had one version of the compiler ... and I do suspect
   that with multiple versions it will not be enough

--
Roberto

On Wed, Jan 16, 2013 at 06:46:35PM +0100, Fabrice Le Fessant wrote:
> On 01/16/2013 06:40 PM, Thomas Gazagnaire wrote:
> >>I would suggest that OPAM should always set the variable OCAMLFIND_CONF to $HOME/.opam/$COMPILER/lib/findlib.conf, so that, whatever the "ocamlfind" that ocamlbuild uses, it will always use the packages installed by OPAM.
> >
> >I've tried that and unfortunately this didn't seem to work. ocamlfind is picking the wrong compiler.
> 
> We just tried it with Roberto, and it worked.
> 
> --Fabrice
> 
> -- 
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

-- 
Roberto Di Cosmo
 
------------------------------------------------------------------
Professeur               En delegation a l'INRIA
PPS                      E-mail: roberto@dicosmo.org
Universite Paris Diderot WWW  : http://www.dicosmo.org
Case 7014                Tel  : ++33-(0)1-57 27 92 20
5, Rue Thomas Mann       
F-75205 Paris Cedex 13   Identica: http://identi.ca/rdicosmo
FRANCE.                  Twitter: http://twitter.com/rdicosmo
------------------------------------------------------------------
Attachments:
MIME accepted, Word deprecated
      http://www.gnu.org/philosophy/no-word-attachments.html
------------------------------------------------------------------
Office location:
 
Bureau 6C08 (6th floor)
175, rue du Chevaleret, XIII
Metro Chevaleret, ligne 6
-----------------------------------------------------------------
GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3                        

[Caml-list] Re: [ANN] beta-release of OPAM

[Sylvain Le Gall]

On 15-01-2013, Daniel Bünzli <daniel.buenzli@erratique.ch> wrote:
> Le mardi, 15 janvier 2013 à 16:40, Thomas Gazagnaire a écrit :
>> if you have developed packages which are already in OPAM do not hesitate to claim their ownership and to improve their description - if your packages are not yet in, it's time to start packaging them!
>
> At a certain point I plan to do so. Is there, however, any known
> tool/scripts that can help me to streamline this process via the
> _oasis file of my packages ? This file already contains ammost
> everything: a package name, version, synopsis, description and
> (implicit) build instructions (see [1] for an example).

I wish such a tool exists. Technically speaking nothing prevent that, I
think this is just a matter of someone taking the time to write such a
tool.

The GODI/OASIS, Debian/OASIS and ODB/OASIS integration are already doing
that, for other package manager.
http://godi.camlcity.org/godi/oasis.html
http://anonscm.debian.org/gitweb/?p=pkg-ocaml-maint/packages/oasis2debian.git;a=summary

If you start such a tool, please share.


Cheers,
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall
Start an OCaml project here: http://forge.ocamlcore.org
OCaml blogs:                 http://planet.ocamlcore.org

Re: [Caml-list] [ANN] beta-release of OPAM

[Alain Frisch]

Hi Thomas,

Is there a way to tell OPAM to install from INRIA's SVN repository 
(either the trunk or a specific branch), and to update on demand?

Alain

Re: [Caml-list] [ANN] beta-release of OPAM

[Anil Madhavapeddy]

I added `opam switch 4.01.0dev+trunk` recently, which will grab the latest trunk snapshot.
To reinstall it and refresh to a newer snapshot, just do `opam switch reinstall 4.01.0dev+trunk`, which will also attempt to recompile any packages you had in there before.

It's also pretty easy to add your own branches; see
https://github.com/OCamlPro/opam-repository/blob/master/compilers/4.01.0dev%2Btrunk.comp
...for the trunk description, and there are several others out there.

Pierre is maintaining his various optimisation patches in his repository as an example, so you can see how to maintain custom branches as normal OPAM remotes (just like for packages).
https://github.com/chambart/opam-compilers-repository

Note that SVN isn't directly supported by OPAM (only Darcs and Git), so all of these are using the SVN->Git mirror at http://github.com/ocaml/ocaml, which is updated every hour via our friendly double-humped Bactrian Github bot.  Let us know how you get along with this!

-anil

On 17 Jan 2013, at 17:15, Alain Frisch <alain@frisch.fr> wrote:

> Hi Thomas,
> 
> Is there a way to tell OPAM to install from INRIA's SVN repository (either the trunk or a specific branch), and to update on demand?
> 
> Alain
> 

[Caml-list] Re: [ANN] beta-release of OPAM

[Hongbo Zhang]

On 1/15/13 10:40 AM, Thomas Gazagnaire wrote:
> I'm very happy to announce the beta release of OPAM (0.9.1). OPAM is a package manager for OCaml to install libraries and tools from source archives. It supports multiple simultaneous compiler installations, flexible package constraints, and a Git-friendly development workflow.
>
Opam is the best package manager for ocaml I have ever used, thanks for 
your hard work!
> The goal of this beta release is to formally introduce OPAM to the community, to gather some general feedback on the documentation and tools and double-check that we've not forgotten some useful features. I would also like to use that opportunity to make an official call to maintainers: if you have developed packages which are already in OPAM do not hesitate to claim their ownership and to improve their description - if your packages are not yet in, it's time to start packaging them!
>
> OPAM is developed by OCamlPro[1] and has been in alpha release since June 2012. It is already quite mature and has gained some nice momentum (+40 contributors, +300 packages).  OPAM has been initially funded by Jane Street[2] and the DORM EU research project, and it has received continuous help and resources from OCamlLabs[3].
>
> The source code of OPAM is available on Github:
> * installer: https://github.com/OCamlpro/opam
> * packages and compiler descriptions: https://github.com/OCamlPro/opam-repository
> * website: https://github.com/OCamlPro/opam2web
>
> The documention:
> * install instructions and tutorial are available http://opam.ocamlpro.com/
> * the main source of documentation is 'opam --help' or 'opam <command> --help'
> * user manual: https://github.com/OCamlPro/opam/raw/master/doc/dev-manual/dev-manual.pdf
>
> You can report issues on github bug tracker:
> * https://github.com/OCamlPro/opam/issues
>
> The next steps for us is to focus on improving the package descriptions quality and the global consistency of https://github.com/OCamlPro/opam-repository. We will gladly accept any kind of help and support from the community to do this!  We plan to announce the release of 1.0.0 in a couple of months, with improved package quality and better integration with the future OCaml platform.
>
> Last point, if you are working in a company and that you already use OPAM, or plan to use OPAM, and you would like to help us ensuring it a sustainable future[2], you can contact us at contact@ocamlpro.com.
>
> On behalf of the OPAM team,
> Thomas Gazagnaire
>
> [1] http://www.ocamlpro.com/
> [2] http://www.janestreet.com/
> [3] http://www.cl.cam.ac.uk/projects/ocamllabs/
>
>
>

Re: [Caml-list] [ANN] beta-release of OPAM

[Alain Frisch]

On 01/17/2013 06:22 PM, Anil Madhavapeddy wrote:
> I added `opam switch 4.01.0dev+trunk` recently, which will grab the latest trunk snapshot.
> To reinstall it and refresh to a newer snapshot, just do `opam switch reinstall 4.01.0dev+trunk`, which will also attempt to recompile any packages you had in there before.

Thanks, this is exactly what I wanted!

Shouldn't the package be called simply "trunk", without a reference to a 
version number?


I've started to play with opam a little bit, and it's a surprisingly 
pleasant experience.  Thanks to everyone who contributed to this project!

Now I want to create my first package.  I've followed the instructions 
from http://opam.ocamlpro.com/doc/Packaging.html but I don't know where 
to find opam-mk-repo (I've installed opam from the amd64 linux binary).

Alain

Re: [Caml-list] [ANN] beta-release of OPAM

[Anil Madhavapeddy]

On 18 Jan 2013, at 10:31, Alain Frisch <alain@frisch.fr> wrote:

> On 01/17/2013 06:22 PM, Anil Madhavapeddy wrote:
>> I added `opam switch 4.01.0dev+trunk` recently, which will grab the latest trunk snapshot.
>> To reinstall it and refresh to a newer snapshot, just do `opam switch reinstall 4.01.0dev+trunk`, which will also attempt to recompile any packages you had in there before.
> 
> Thanks, this is exactly what I wanted!
> 
> Shouldn't the package be called simply "trunk", without a reference to a version number?

Yeah, but OPAM also has compiler version constraints, so that you can mark a package as requiring {>=4.00} for example.  If the package is just marked trunk, then we need to manually record the version number somewhere.

One option is to have a very high version, so that any packages with a lower bound will continue to work.  The other option (which I chose) is to pick the current working version, since compiler releases only happen a couple of times a year.  We can improve on this...

> I've started to play with opam a little bit, and it's a surprisingly pleasant experience.  Thanks to everyone who contributed to this project!
> 
> Now I want to create my first package.  I've followed the instructions from http://opam.ocamlpro.com/doc/Packaging.html but I don't know where to find opam-mk-repo (I've installed opam from the amd64 linux binary).

(that binary is hopefully just a stopgap until the OPAM binary packages become more widely available)

opam-mk-repo is installed as part of OPAM, so you'll need to install from source.  However, you don't actually need to create a repository unless you want to host a mirror of the tarballs.  Simply try this:

$ mkdir -p my-repo/packages
$ opam remote add localdev my-repo
<create your package inside my-repo/packages/>
$ opam update
<the new packages will be available>
$ opam install <new-package>

The same applies for compilers.

If you specify a git:// or darcs:// URL in the package `url` file, a subsequent `opam update` will refresh the working copy from the remote source.

If you want to work with a local copy of that package, just do `opam pin <package> <dir>`.

If you want the bleeding edge version of a stable package, you can even do `opam pin <package> git://foo/bar`.

Quite the swiss-army knife, but each of those scenarios has come in useful at one point or another, particularly when hacking on Mirage which requires rebuilding lots of forward dependencies if (e.g.) a network driver library is being modified.

-anil

Re: [Caml-list] [ANN] beta-release of OPAM

[Fabrice Le Fessant]

Have we started an FAQ for OPAM ?

Sounds like the two questions and answers would deserve to be included 
in such an FAQ (with a copy on StackOverflow).

--Fabrice


On 01/18/2013 11:42 AM, Anil Madhavapeddy wrote:
> On 18 Jan 2013, at 10:31, Alain Frisch <alain@frisch.fr> wrote:
>
>> On 01/17/2013 06:22 PM, Anil Madhavapeddy wrote:
>>> I added `opam switch 4.01.0dev+trunk` recently, which will grab the latest trunk snapshot.
>>> To reinstall it and refresh to a newer snapshot, just do `opam switch reinstall 4.01.0dev+trunk`, which will also attempt to recompile any packages you had in there before.
>>
>> Thanks, this is exactly what I wanted!
>>
>> Shouldn't the package be called simply "trunk", without a reference to a version number?
>
> Yeah, but OPAM also has compiler version constraints, so that you can mark a package as requiring {>=4.00} for example.  If the package is just marked trunk, then we need to manually record the version number somewhere.
>
> One option is to have a very high version, so that any packages with a lower bound will continue to work.  The other option (which I chose) is to pick the current working version, since compiler releases only happen a couple of times a year.  We can improve on this...
>
>> I've started to play with opam a little bit, and it's a surprisingly pleasant experience.  Thanks to everyone who contributed to this project!
>>
>> Now I want to create my first package.  I've followed the instructions from http://opam.ocamlpro.com/doc/Packaging.html but I don't know where to find opam-mk-repo (I've installed opam from the amd64 linux binary).
>
> (that binary is hopefully just a stopgap until the OPAM binary packages become more widely available)
>
> opam-mk-repo is installed as part of OPAM, so you'll need to install from source.  However, you don't actually need to create a repository unless you want to host a mirror of the tarballs.  Simply try this:
>
> $ mkdir -p my-repo/packages
> $ opam remote add localdev my-repo
> <create your package inside my-repo/packages/>
> $ opam update
> <the new packages will be available>
> $ opam install <new-package>
>
> The same applies for compilers.
>
> If you specify a git:// or darcs:// URL in the package `url` file, a subsequent `opam update` will refresh the working copy from the remote source.
>
> If you want to work with a local copy of that package, just do `opam pin <package> <dir>`.
>
> If you want the bleeding edge version of a stable package, you can even do `opam pin <package> git://foo/bar`.
>
> Quite the swiss-army knife, but each of those scenarios has come in useful at one point or another, particularly when hacking on Mirage which requires rebuilding lots of forward dependencies if (e.g.) a network driver library is being modified.
>
> -anil
>

Re: [Caml-list] [ANN] beta-release of OPAM

[Alain Frisch]

On 01/18/2013 11:42 AM, Anil Madhavapeddy wrote:
> On 18 Jan 2013, at 10:31, Alain Frisch <alain@frisch.fr> wrote:
>> Shouldn't the package be called simply "trunk", without a reference to a version number?
>
> Yeah, but OPAM also has compiler version constraints, so that you can mark a package as requiring {>=4.00} for example.

Understood.

> $ mkdir -p my-repo/packages
> $ opam remote add localdev my-repo
> <create your package inside my-repo/packages/>
> $ opam update
> <the new packages will be available>
> $ opam install <new-package>

Thanks.  That's what I've done.

I've sent my first "pull request" for the inclusion of a new package in 
OPAM :-)


Are there plans to provide a more direct way to submit proposals for new 
packages?  If I understand correctly, the current scheme requires to 
create an account on github, fork the opam-repository, clone the fork 
locally, create and commit the package locally, push it to github, and 
then create a pull request.  Admittedly, this is not difficult once 
you're familiar with GIT and github, but I can imagine that it will 
still discourage some people from submitting their first package.  What 
about a simple web interface to upload a .tar.gz of the package 
description, for instance?  It should not be too hard to automate the 
treatment of uploaded package descriptions.

Alain

Re: [Caml-list] [ANN] beta-release of OPAM

[Anil Madhavapeddy]

On 18 Jan 2013, at 11:19, Alain Frisch <alain@frisch.fr> wrote:
> 
> I've sent my first "pull request" for the inclusion of a new package in OPAM :-)

Yay!

> Are there plans to provide a more direct way to submit proposals for new packages?  If I understand correctly, the current scheme requires to create an account on github, fork the opam-repository, clone the fork locally, create and commit the package locally, push it to github, and then create a pull request.  Admittedly, this is not difficult once you're familiar with GIT and github, but I can imagine that it will still discourage some people from submitting their first package.  What about a simple web interface to upload a .tar.gz of the package description, for instance?  It should not be too hard to automate the treatment of uploaded package descriptions.

A certain barrier to entry in the early days isn't a bad thing. Homebrew seems to cope well enough with this workflow (with over 10,000 forks).   We should probably add a CONTRIBUTING file with clear instructions to `opam-repository`.

However, I do have ocaml-github [1] bindings now which we're using for comment reporting in Real World OCaml (so that comments reported via the website version are converted into Github issues for us to parse). It should be straightforward to support for this to OPAM. 

Thomas just added (in trunk) a git-like extension mechanism to OPAM which will be suitable for this purpose.  If you execute an unknown subcommand, say `opam foo bar`, it will look for the `opam-foo` binary and execute it with the sub arguments.

This should be sufficient to build an `opam-upload` command that has all the Github dependencies, without making the base OPAM package more complicated to build.  I'm still working on a stable release of Cohttp, which the Github bindings depend on, so it's important that OPAM remains easy to bootstrap without requiring zillions of bleeding-edge dependencies.

-anil

[1] opam install github

Re: [Caml-list] [ANN] beta-release of OPAM

[aditya siram]

[-- Attachment #1: Type: text/plain, Size: 5166 bytes --]

Hi,
Installing OPAM worked fine, but most of the packages won't install because
of issues with ocamlfind.

> opam install ocamlfind
The following actions will be performed:
 - install ocamlfind.1.3.3
1 to install | 0 to reinstall | 0 to upgrade | 0 to downgrade | 0 to remove

=-=-= ocamlfind.1.3.3 =-=-=
The archive for ocamlfind.1.3.3 is in the local cache.
Extracting /home/deech/.opam/archives/ocamlfind.1.3.3+opam.tar.gz.
Building ocamlfind.1.3.3:
  ./configure -bindir /home/deech/.opam/system/bin -sitelib
/home/deech/.opam/system/lib -mandir /home/deech/.opam/system/man -config
/home/deech/.opam/system/lib/findlib.conf -no-topfind
  make all
  make opt
  make install
  ocamlfind remove dbm
The compilation of ocamlfind.1.3.3 failed.


==== ERROR [while installing ocamlfind.1.3.3] ====
# command         make all
# path            /home/deech/.opam/system/build/ocamlfind.1.3.3
# exit-code       2
# env-file
/home/deech/.opam/system/build/ocamlfind.1.3.3/ocamlfind-1872ec.env
# stdout-file
/home/deech/.opam/system/build/ocamlfind.1.3.3/ocamlfind-1872ec.out
# stderr-file
/home/deech/.opam/system/build/ocamlfind.1.3.3/ocamlfind-1872ec.err
### stdout ###
...[truncated]
ocamlc -I +compiler-libs -g -c findlib.ml
ocamlc -I +compiler-libs -g -c fl_args.ml
ocamlc -I +compiler-libs -a -o findlib.cma findlib_config.cmo fl_split.cmo
fl_metatoken.cmo fl_meta.cmo fl_metascanner.cmo fl_topo.cmo
fl_package_base.cmo findlib.cmo fl_args.cmo
ocamlc -I +compiler-libs -g -c ocaml_args.ml
ocamlc -I +compiler-libs -g -c frontend.ml
ocamlc -I +compiler-libs -custom -o ocamlfind -g findlib.cma unix.cma \
                   ocaml_args.cmo frontend.cmo
ocamlc -I +compiler-libs -c topfind.mli
ocamlc -I +compiler-libs -g -c topfind.ml
make[1]: Leaving directory
`/home/deech/.opam/system/build/ocamlfind.1.3.3/src/findlib'
### stderr ###
...[truncated]
Warning 26: unused variable in_direction.
File "topfind.ml", line 53, characters 10-19:
Warning 26: unused variable stdlibdir.
File "topfind.ml", line 97, characters 11-12:
Warning 26: unused variable d.
File "topfind.ml", line 1, characters 0-1:
Error: /usr/local/lib/ocaml/compiler-libs/topdirs.cmi
is not a compiled interface
make[1]: *** [topfind.cmo] Error 2
make: *** [all] Error 2

'/usr/local/bin/opam install ocamlfind' failed.

My Ocaml version is 3.12.1

-deech


On Tue, Jan 15, 2013 at 9:40 AM, Thomas Gazagnaire <thomas@ocamlpro.com>wrote:

> I'm very happy to announce the beta release of OPAM (0.9.1). OPAM is a
> package manager for OCaml to install libraries and tools from source
> archives. It supports multiple simultaneous compiler installations,
> flexible package constraints, and a Git-friendly development workflow.
>
> The goal of this beta release is to formally introduce OPAM to the
> community, to gather some general feedback on the documentation and tools
> and double-check that we've not forgotten some useful features. I would
> also like to use that opportunity to make an official call to maintainers:
> if you have developed packages which are already in OPAM do not hesitate to
> claim their ownership and to improve their description - if your packages
> are not yet in, it's time to start packaging them!
>
> OPAM is developed by OCamlPro[1] and has been in alpha release since June
> 2012. It is already quite mature and has gained some nice momentum (+40
> contributors, +300 packages).  OPAM has been initially funded by Jane
> Street[2] and the DORM EU research project, and it has received continuous
> help and resources from OCamlLabs[3].
>
> The source code of OPAM is available on Github:
> * installer: https://github.com/OCamlpro/opam
> * packages and compiler descriptions:
> https://github.com/OCamlPro/opam-repository
> * website: https://github.com/OCamlPro/opam2web
>
> The documention:
> * install instructions and tutorial are available
> http://opam.ocamlpro.com/
> * the main source of documentation is 'opam --help' or 'opam <command>
> --help'
> * user manual:
> https://github.com/OCamlPro/opam/raw/master/doc/dev-manual/dev-manual.pdf
>
> You can report issues on github bug tracker:
> * https://github.com/OCamlPro/opam/issues
>
> The next steps for us is to focus on improving the package descriptions
> quality and the global consistency of
> https://github.com/OCamlPro/opam-repository. We will gladly accept any
> kind of help and support from the community to do this!  We plan to
> announce the release of 1.0.0 in a couple of months, with improved package
> quality and better integration with the future OCaml platform.
>
> Last point, if you are working in a company and that you already use OPAM,
> or plan to use OPAM, and you would like to help us ensuring it a
> sustainable future[2], you can contact us at contact@ocamlpro.com.
>
> On behalf of the OPAM team,
> Thomas Gazagnaire
>
> [1] http://www.ocamlpro.com/
> [2] http://www.janestreet.com/
> [3] http://www.cl.cam.ac.uk/projects/ocamllabs/
>
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

[-- Attachment #2: Type: text/html, Size: 7173 bytes --]

Opam package publication (was Re: [Caml-list] [ANN] beta-release of OPAM)

[Daniel Bünzli]

Le vendredi, 18 janvier 2013 à 12:27, Anil Madhavapeddy a écrit :
> A certain barrier to entry in the early days isn't a bad thing. Homebrew seems to cope well enough with this workflow (with over 10,000 forks).

For now my packages where uploaded by a kind contributor (thanks to him) but in the future I intend to do so myself and I share Alain Frisch's sentiment here.

I also find the github process rather wasteful in terms of energy, moreover if a submitted package is rejected or if the pull request gets stuck for a while and I need to provide the package to someone else rapidly then I'll have to publish it a second time on another repo.

I think it would be easier to tell packagers to provide their own http repository and have a simple command in opam that allows to import a package from one repository in another.

That way I publish my packages once on a website and it ensures they are available whether ocamlpro wants them in their repo or not. I notify ocamlpro's repository maintainer (in a way to be specified by him) of the existence of the package and he can import it from my repo if he wishes. If for some reason the package never makes it in ocamlpro's repository, the end-user can just add my repo to its opam install to get it immediatly.

This solves a lot of problems very easily, without wasting too much energy, in a distributed manner and without github in the loop.

Best,

Daniel

Re: [Caml-list] [ANN] beta-release of OPAM

[Thomas Gazagnaire]

> Error: /usr/local/lib/ocaml/compiler-libs/topdirs.cmi
> is not a compiled interface
> make[1]: *** [topfind.cmo] Error 2
> make: *** [all] Error 2

This seems to indicate that your compiler installation is a bit screwed up. Are you able to compile ocamlfind from sources ? Have you updated your OCaml installation recently ? Which version are you using ?

--

Thomas



> '/usr/local/bin/opam install ocamlfind' failed.
> 
> My Ocaml version is 3.12.1
> 
> -deech
> 
> 
> On Tue, Jan 15, 2013 at 9:40 AM, Thomas Gazagnaire <thomas@ocamlpro.com> wrote:
> I'm very happy to announce the beta release of OPAM (0.9.1). OPAM is a package manager for OCaml to install libraries and tools from source archives. It supports multiple simultaneous compiler installations, flexible package constraints, and a Git-friendly development workflow.
> 
> The goal of this beta release is to formally introduce OPAM to the community, to gather some general feedback on the documentation and tools and double-check that we've not forgotten some useful features. I would also like to use that opportunity to make an official call to maintainers: if you have developed packages which are already in OPAM do not hesitate to claim their ownership and to improve their description - if your packages are not yet in, it's time to start packaging them!
> 
> OPAM is developed by OCamlPro[1] and has been in alpha release since June 2012. It is already quite mature and has gained some nice momentum (+40 contributors, +300 packages).  OPAM has been initially funded by Jane Street[2] and the DORM EU research project, and it has received continuous help and resources from OCamlLabs[3].
> 
> The source code of OPAM is available on Github:
> * installer: https://github.com/OCamlpro/opam
> * packages and compiler descriptions: https://github.com/OCamlPro/opam-repository
> * website: https://github.com/OCamlPro/opam2web
> 
> The documention:
> * install instructions and tutorial are available http://opam.ocamlpro.com/
> * the main source of documentation is 'opam --help' or 'opam <command> --help'
> * user manual: https://github.com/OCamlPro/opam/raw/master/doc/dev-manual/dev-manual.pdf
> 
> You can report issues on github bug tracker:
> * https://github.com/OCamlPro/opam/issues
> 
> The next steps for us is to focus on improving the package descriptions quality and the global consistency of https://github.com/OCamlPro/opam-repository. We will gladly accept any kind of help and support from the community to do this!  We plan to announce the release of 1.0.0 in a couple of months, with improved package quality and better integration with the future OCaml platform.
> 
> Last point, if you are working in a company and that you already use OPAM, or plan to use OPAM, and you would like to help us ensuring it a sustainable future[2], you can contact us at contact@ocamlpro.com.
> 
> On behalf of the OPAM team,
> Thomas Gazagnaire
> 
> [1] http://www.ocamlpro.com/
> [2] http://www.janestreet.com/
> [3] http://www.cl.cam.ac.uk/projects/ocamllabs/
> 
> 
> 
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 

Re: Opam package publication (was Re: [Caml-list] [ANN] beta-release of OPAM)

[Philippe Veber]

[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]

Hi Daniel,

I hope I understood your point correctly, but you can already do that : if
your repo is accessible via git, http or rsync protocols any user can use
it simultaneously with ocamlpro's. opam has no problem handling several
repositories and makes a good job of sorting out which repo has the newest
version of a package. In practice it works very well. Details can be found
there: http://opam.ocamlpro.com/doc/Advanced_Usage.html (see Handling of
repositories).

cheers,
  Philippe.

2013/1/18 Daniel Bünzli <daniel.buenzli@erratique.ch>

> Le vendredi, 18 janvier 2013 à 12:27, Anil Madhavapeddy a écrit :
> > A certain barrier to entry in the early days isn't a bad thing. Homebrew
> seems to cope well enough with this workflow (with over 10,000 forks).
>
> For now my packages where uploaded by a kind contributor (thanks to him)
> but in the future I intend to do so myself and I share Alain Frisch's
> sentiment here.
>
> I also find the github process rather wasteful in terms of energy,
> moreover if a submitted package is rejected or if the pull request gets
> stuck for a while and I need to provide the package to someone else rapidly
> then I'll have to publish it a second time on another repo.
>
> I think it would be easier to tell packagers to provide their own http
> repository and have a simple command in opam that allows to import a
> package from one repository in another.
>
> That way I publish my packages once on a website and it ensures they are
> available whether ocamlpro wants them in their repo or not. I notify
> ocamlpro's repository maintainer (in a way to be specified by him) of the
> existence of the package and he can import it from my repo if he wishes. If
> for some reason the package never makes it in ocamlpro's repository, the
> end-user can just add my repo to its opam install to get it immediatly.
>
> This solves a lot of problems very easily, without wasting too much
> energy, in a distributed manner and without github in the loop.
>
> Best,
>
> Daniel
>
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

[-- Attachment #2: Type: text/html, Size: 2950 bytes --]

Re: Opam package publication (was Re: [Caml-list] [ANN] beta-release of OPAM)

[Daniel Bünzli]

Le samedi, 19 janvier 2013 à 10:07, Philippe Veber a écrit :
> I hope I understood your point correctly, but you can already do that : if your repo is accessible via git, http or rsync protocols any user can use it simultaneously with ocamlpro's.

Yes, I know, that was not the point. I was proposing a lighter process for a package to be included in opam's default repository.  

As Alain mentioned, the current process is rather involved for package developers --- but I disagree with his idea of an upload web interface.  

The idea is that package developers publish repos with their work and that there's a kind of `import` or `copy` command in opam that allows to copy a package from one repo to another (this could also be useful to make custom repos). ocamlpro uses this command to transfer a package from the developer's repo to the default repo.

This allows package users that are confident in a packager to use his repo directly, and those that prefer to wait for the inclusion in opam default repo to wait for it while minimizing the overall energy spent for all the involved parties.  

Best,

Daniel

Re: Opam package publication (was Re: [Caml-list] [ANN] beta-release of OPAM)

[Thomas Gazagnaire]

> Yes, I know, that was not the point. I was proposing a lighter process for a package to be included in opam's default repository.  
> 
> As Alain mentioned, the current process is rather involved for package developers --- but I disagree with his idea of an upload web interface.  

I agree that the current process is a little bit involved for people not very used to git and github. OPAM already has an very basic 'opam update' command which I'm quite keen to see improved if people found it necessary (eg. patches are very welcome).

> The idea is that package developers publish repos with their work and that there's a kind of `import` or `copy` command in opam that allows to copy a package from one repo to another (this could also be useful to make custom repos). ocamlpro uses this command to transfer a package from the developer's repo to the default repo.

Homebrew use the concept of 'taps' where people can register alternative repositories, which will contain domain-specific packages (ocaml uses to have one before being integrated in the main repo). Doing that for OPAM is (I think) a bit overkill. However, I'm happy to have a REPOSITORIES file at the root of OCamlPro/opam-repositories which lists the available repositories, and write a small script to automatically sync with these repo regularly. Feel free to add your repository in there, and I'll write the update script.

> This allows package users that are confident in a packager to use his repo directly, and those that prefer to wait for the inclusion in opam default repo to wait for it while minimizing the overall energy spent for all the involved parties.  

Agreed, this sounds a good idea to me.

--
Thomas

Re: [Caml-list] [ANN] beta-release of OPAM

[Thomas Gazagnaire]

> Have we started an FAQ for OPAM ?

I've created a FAQ with these two questions on OPAM wiki: https://github.com/OCamlPro/opam/wiki/FAQ

Feel free to edit and contribute!

(once we get sufficiently nice contents, this can automatically go somewhere on opam.ocamlpro.com as the other wiki pages).

--
Thomas

> 
> Sounds like the two questions and answers would deserve to be included in such an FAQ (with a copy on StackOverflow).
> 
> --Fabrice
> 
> 
> On 01/18/2013 11:42 AM, Anil Madhavapeddy wrote:
>> On 18 Jan 2013, at 10:31, Alain Frisch <alain@frisch.fr> wrote:
>> 
>>> On 01/17/2013 06:22 PM, Anil Madhavapeddy wrote:
>>>> I added `opam switch 4.01.0dev+trunk` recently, which will grab the latest trunk snapshot.
>>>> To reinstall it and refresh to a newer snapshot, just do `opam switch reinstall 4.01.0dev+trunk`, which will also attempt to recompile any packages you had in there before.
>>> 
>>> Thanks, this is exactly what I wanted!
>>> 
>>> Shouldn't the package be called simply "trunk", without a reference to a version number?
>> 
>> Yeah, but OPAM also has compiler version constraints, so that you can mark a package as requiring {>=4.00} for example.  If the package is just marked trunk, then we need to manually record the version number somewhere.
>> 
>> One option is to have a very high version, so that any packages with a lower bound will continue to work.  The other option (which I chose) is to pick the current working version, since compiler releases only happen a couple of times a year.  We can improve on this...
>> 
>>> I've started to play with opam a little bit, and it's a surprisingly pleasant experience.  Thanks to everyone who contributed to this project!
>>> 
>>> Now I want to create my first package.  I've followed the instructions from http://opam.ocamlpro.com/doc/Packaging.html but I don't know where to find opam-mk-repo (I've installed opam from the amd64 linux binary).
>> 
>> (that binary is hopefully just a stopgap until the OPAM binary packages become more widely available)
>> 
>> opam-mk-repo is installed as part of OPAM, so you'll need to install from source.  However, you don't actually need to create a repository unless you want to host a mirror of the tarballs.  Simply try this:
>> 
>> $ mkdir -p my-repo/packages
>> $ opam remote add localdev my-repo
>> <create your package inside my-repo/packages/>
>> $ opam update
>> <the new packages will be available>
>> $ opam install <new-package>
>> 
>> The same applies for compilers.
>> 
>> If you specify a git:// or darcs:// URL in the package `url` file, a subsequent `opam update` will refresh the working copy from the remote source.
>> 
>> If you want to work with a local copy of that package, just do `opam pin <package> <dir>`.
>> 
>> If you want the bleeding edge version of a stable package, you can even do `opam pin <package> git://foo/bar`.
>> 
>> Quite the swiss-army knife, but each of those scenarios has come in useful at one point or another, particularly when hacking on Mirage which requires rebuilding lots of forward dependencies if (e.g.) a network driver library is being modified.
>> 
>> -anil
>> 
> 
> -- 
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: Opam package publication (was Re: [Caml-list] [ANN] beta-release of OPAM)

[Daniel Bünzli]

Le mardi, 22 janvier 2013 à 16:46, Thomas Gazagnaire a écrit :
> Homebrew use the concept of 'taps' where people can register alternative repositories, which will contain domain-specific packages (ocaml uses to have one before being integrated in the main repo). Doing that for OPAM is (I think) a bit overkill.  

Well to me it seems that opam already has the concept, tap = repo (or maybe I don't understand what a homebrew tap is).
  
> However, I'm happy to have a REPOSITORIES file at the root of OCamlPro/opam-repositories which lists the available repositories, and write a small script to automatically sync with these repo regularly. Feel free to add your repository in there, and I'll write the update script.

Feels like a step in the right direction to me. But I don't think it's a good idea to make it fully automatic or at least something sensitive should be done to handle potential conflicts.

Best,

Daniel

Re: Opam package publication (was Re: [Caml-list] [ANN] beta-release of OPAM)

[Alain Frisch]

On 01/19/2013 11:40 AM, Daniel Bünzli wrote:
> Yes, I know, that was not the point. I was proposing a lighter process for a package to be included in opam's default repository.
>
> As Alain mentioned, the current process is rather involved for package developers --- but I disagree with his idea of an upload web interface.
>
> The idea is that package developers publish repos with their work

Concretely, I guess that publish a repo means setting up a server 
somewhere.  I don't think that everyone can easily do that or want to 
invest so much effort only to submit a single package.

What's the benefit of the git/github submission workflow?  I don't 
immediately see how this is easier for people responsible of 
accepting/rejection packages than, say, something based on an upload 
interface (or even simpler, an email with an attachment).

-- Alain

Re: Opam package publication (was Re: [Caml-list] [ANN] beta-release of OPAM)

[Thomas Gazagnaire]

>> Homebrew use the concept of 'taps' where people can register alternative repositories, which will contain domain-specific packages (ocaml uses to have one before being integrated in the main repo). Doing that for OPAM is (I think) a bit overkill.  
> 
> Well to me it seems that opam already has the concept, tap = repo (or maybe I don't understand what a homebrew tap is).

Yes, that's pretty similar, but 'brew search' will also search into some pre-defined taps and you have predefined names for some of them. I just don't feel we need such tight integration in OPAM.

>> However, I'm happy to have a REPOSITORIES file at the root of OCamlPro/opam-repositories which lists the available repositories, and write a small script to automatically sync with these repo regularly. Feel free to add your repository in there, and I'll write the update script.
> 
> Feels like a step in the right direction to me. But I don't think it's a good idea to make it fully automatic or at least something sensitive should be done to handle potential conflicts.

By automatic, I mean, we can have a script looking at the new packages available and create pull request for them in opam-repository (and we can continue to use the same workflow).

Thomas

Re: Opam package publication (was Re: [Caml-list] [ANN] beta-release of OPAM)

[Fabrice Le Fessant]

On 01/22/2013 05:35 PM, Alain Frisch wrote:
> What's the benefit of the git/github submission workflow?  I don't
> immediately see how this is easier for people responsible of
> accepting/rejection packages than, say, something based on an upload
> interface (or even simpler, an email with an attachment).

I think one advantage of the github submission workflow is that 
everybody can comment on a pull-request, ask for modifications, until 
the patch seems ok for acceptance.

I "opamised" the unstable branch of TypeRex this week (mostly to provide 
access to the new version of ocp-build, not for the editor that is not 
ready), and I wrote a simple program "ocp-opamer" to simplify the 
workflow (it is installed with TypeRex 1.99.1-beta) :

1/ you fork the opam-repository on GitHub
2/ for your package "foobar", you call:

ocp-opamer -login your-github-login -opam foobar.opam -descr 
foobar.descr foobar 1.2.3 http://an.url.for/the.tarball.tgz

It will checkout your opam-repository, create the sub-directory and the 
'url' file with the md5sum after downloading archive, and upload a new 
branch 'foobar' to your repository.

3/ from your repository, you send a pull-request to the main rep, for 
branch 'foobar'

Does it sound so complex ? For TypeRex, step (2) is a rule in the 
Makefile, step (1) has to be done once, and (3) is quite simple...

If you think the tool is worth it, it could be added to an "opam-tools" 
package in the future...

--Fabrice

Re: Opam package publication (was Re: [Caml-list] [ANN] beta-release of OPAM)

[Thomas Gazagnaire]

> Concretely, I guess that publish a repo means setting up a server somewhere.  I don't think that everyone can easily do that or want to invest so much effort only to submit a single package.
> 
> What's the benefit of the git/github submission workflow?  I don't immediately see how this is easier for people responsible of accepting/rejection packages than, say, something based on an upload interface (or even simpler, an email with an attachment).

The goal is to have external tools looking at all pull request, running tests, and giving quality feedback to opam-repository gatekeepers. Pull requests are also a good place to start discussion about packages. This can be done outside of github (on a mailing list for instance) but that's mean reinventing the wheel as github pull-request worflow is actually specifically designed for this. But as I said, I'm happy to help people submit packages more easily, so having an 'opam-tools' package with command-line interfaces to help packager could be a good idea.

Thomas

Re: Opam package publication (was Re: [Caml-list] [ANN] beta-release of OPAM)

[Daniel Bünzli]

Le mardi, 22 janvier 2013 à 17:35, Alain Frisch a écrit :
> Concretely, I guess that publish a repo means setting up a server
> somewhere. I don't think that everyone can easily do that or want to  
> invest so much effort only to submit a single package.

Concretely it means being able to publish text files available over http which these days doesn't feel like a huge problem. It goes along with your package's homepage (I personally wouldn't anyway use a package that hasn't any web presence in some way).  

Best,

Daniel

P.S. My perspective is also certainly biased as I currently develop/maintain around ten packages and expect this number to grow in the future. The smallest modular unit of functionality approach has a bureaucratic cost and I try by all means to minimize it.

Re: Opam package publication (was Re: [Caml-list] [ANN] beta-release of OPAM)

[Daniel Bünzli]

Le mardi, 22 janvier 2013 à 17:48, Thomas Gazagnaire a écrit :
> By automatic, I mean, we can have a script looking at the new packages available and create pull request for them in opam-repository (and we can continue to use the same workflow).

For me that would be great.  

Best,

Daniel

Re: Opam package publication (was Re: [Caml-list] [ANN] beta-release of OPAM)

[Anil Madhavapeddy]

On 22 Jan 2013, at 16:35, Alain Frisch <alain@frisch.fr> wrote:

> On 01/19/2013 11:40 AM, Daniel Bünzli wrote:
>> Yes, I know, that was not the point. I was proposing a lighter process for a package to be included in opam's default repository.
>> 
>> As Alain mentioned, the current process is rather involved for package developers --- but I disagree with his idea of an upload web interface.
>> 
>> The idea is that package developers publish repos with their work
> 
> Concretely, I guess that publish a repo means setting up a server somewhere.  I don't think that everyone can easily do that or want to invest so much effort only to submit a single package.
> 
> What's the benefit of the git/github submission workflow?  I don't immediately see how this is easier for people responsible of accepting/rejection packages than, say, something based on an upload interface (or even simpler, an email with an attachment).


Let's think through what an e-mail workflow might look like rather than just throwing it out as a superior alternative to what we use now.  Let's say it goes to an e-mail list, with a few people subscribed to it.  Then, someone adding the package would reply to the list saying that they'll handle it, and have to deal with it immediately and not get distracted.  Next, we have to convert the package into a Git commit with the submitter's name, so that we have a reasonable package history.  Finally, we need a queue of packages to track which ones haven't been replied to, or else risk forgetting packages.  And of course, anyone who wants to be involved has to subscribe to a mailing list, and the only way to find past submissions is by digging through e-mail archives.

Git/Github takes care of all this, to the point where a merge is a single button on the website.  Specifically, it:

- track provenance of updates (so we can go contact whoever introduced a package reliably, assuming their Github ID doesn't change).

- lets people maintain private branches outside of Github, and easily merge against upstream updates.  Citrix are doing this for their internal repositories, which they re-base against OPAM upstream, and then regularly submit their packages to the mainline once they're tested.  I also do this with Mirage.

- a public tracking system with comments to ensure packages don't get lost. I don't particularly fancy having my mailbox fill up with mailed tar-balls.

- an easy-to-use API that lets us run continuous build directly off Github.  I think of this as "Internet threads". A callback from Github wakes up an Lwt thread to do some work on the continuous build server. That's kind of cool :-)

It should be really trivial to build a package uploader using the OPAM extension mechanism I described earlier, and the ocaml-github bindings. If anyone wants to help add this, get in touch with me and I'll walk you through it.  My plate's a bit too full to get to this in the near-term.

-anil