[Caml-list] ocaml glade gtk3

[Caml-list] ocaml glade gtk3

[r.3]

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


Hello, 

I was using ocaml + lablgtk2 + glade. 
Glade is a tool to graphically design user interfaces. It used to generate glade 2 files (designed for gtk2) until version 3.8. Then I used "lablgladecc2" to convert them in ocaml. 

Now "lablgladecc2" is not appropriate anymore starting with glade 3.10 that generates glade 3 files (designed for gtk3). I was using as a workaround "glade-gtk2" in ubuntu that still generated glade 2 files. But glade-gtk2 is not available anymore in debian, and is not supposed to be available forever in ubuntu. 

Also, lablgtk3 is still in development. 

What do you think is the most sensible thing to do (max benefits, less efforts) ? 

- pray for ocaml glade 3 support 
- forget glade dependency, and hardcode all graphical windows (30 windows to convert maybe ?) in lablgtk2 
- forget glade dependency, and hardcode all graphical windows (30 windows to convert maybe ?) in lablgtk3 
- user standard labltk library (ah ah) 
- other ? 

I whish qtcaml worked, but it is still in dev, I don't think c++ dependencies may be one day overcome, and my project, which is quite big, is under gtk and gtk2. 

Thanks, 
William 


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

Re: [Caml-list] ocaml glade gtk3

[Martin DeMello]

On Mon, Jul 15, 2013 at 7:20 AM,  <r.3@libertysurf.fr> wrote:

> What do you think is the most sensible thing to do (max benefits, less
> efforts) ?
>
> - pray for ocaml glade 3 support
> - forget glade dependency, and hardcode all graphical windows (30 windows to
> convert maybe ?) in lablgtk2
> - forget glade dependency, and hardcode all graphical windows (30 windows to
> convert maybe ?) in lablgtk3
> - user standard labltk library (ah ah)
> - other ?
>
> I whish qtcaml worked, but it is still in dev, I don't think c++
> dependencies may be one day overcome, and my project, which is quite big, is
> under gtk and gtk2.

Under "other", wxocaml is also still in dev, but worth a look
[http://www.ocamlpro.com/blog/2013/04/02/wxocaml-reloaded.html]

martin

[Caml-list] opam and godi

[r.3]

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

Hello, 
could someone explain please the relation between godi and opam ? Is it concurrent ? 
Godi has been there for some time, and works quite nicely. So what are differences ? 
Thanks, 
William 


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

Re: [Caml-list] opam and godi

[Gerd Stolpmann]

> Hello,
> could someone explain please the relation between godi and opam ? Is it
> concurrent ?
> Godi has been there for some time, and works quite nicely. So what are
> differences ?

Hi,

both are independent projects. OPAM is a younger project, and I don't
really know what the motivation behind it is (in addition to the generic
motication to hack something). There were initially claims to make it is
easier to package software up, but what I've seen is actually not much
different from GODI (actually even worse now that GODI allows it to fully
automate package releases).

The feature sets are not the same, and some stuff works better in OPAM and
some in GODI. As I'm advocating the latter, let me point out some features
where I think GODI is better:

 - It supports binary packages as well as source packages. E.g.
   a dedicated build host can distribute binary packages to a
   network.
 - You can force to install archived versions of packages
   (i.e. not only "pin" them but build them from scratch).
   Groups of developers can define the package versions they
   want to work with.
 - Automatic search of system libraries without any need to
   configure these with paths etc.
 - GODI can upgrade itself to a newer version.
 - It has a comprehensive user's manual, also explaining things like
   how to create your own repository.

Gerd


> Thanks,
> William
>
>
> --
> 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


-- 
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.

Re: [Caml-list] opam and godi

[Anil Madhavapeddy]

On 21 Jul 2013, at 14:54, "Gerd Stolpmann" <info@gerd-stolpmann.de> wrote:
> 
>> Hello,
>> could someone explain please the relation between godi and opam ? Is it
>> concurrent ?
>> Godi has been there for some time, and works quite nicely. So what are
>> differences ?
> 
> Hi,
> 
> both are independent projects. OPAM is a younger project, and I don't
> really know what the motivation behind it is (in addition to the generic
> motication to hack something). There were initially claims to make it is
> easier to package software up, but what I've seen is actually not much
> different from GODI (actually even worse now that GODI allows it to fully
> automate package releases).

The answer's right there on the front page:

"OPAM is a source-based package manager for OCaml. It supports multiple
simultaneous compiler installations, flexible package constraints, and a
Git-friendly development workflow."

> The feature sets are not the same, and some stuff works better in OPAM and
> some in GODI. As I'm advocating the latter, let me point out some features
> where I think GODI is better:

Feature minutiae aside, I'd say the biggest benefit of OPAM is the more
open development workflow. It's easier for people to maintain their
own branches and contribute changes to the central repository.

Let's look at the stable repository "pulse":
https://github.com/OCamlPro/opam-repository/pulse/monthly

It tells us that in the last month, there have been 30 authors that have
pushed 167 package updates. These have all come in as pull requests that
can still be browsed.  For example, see the latest Core from Jane Street:
https://github.com/OCamlPro/opam-repository/pulls?state=closed

Several development groups also maintain their own remotes without any
need to depend on the central repository. For example, see Citrix's:
https://github.com/xapi-project/opam-repo-dev/tree/master/packages

As Gerd points out, GODI is an older and more mature project. I find
OPAM more useful for my own personal development workflow though. You
should try both out and see which one you prefer.

cheers,
Anil

Re: [Caml-list] opam and godi

[Yaron Minsky]

While I appreciate the work that Gerd has done on GODI, I do think
that OPAM is a significant improvement over GODI.

From an end-user-experience perspective, I've found OPAM to be
considerably smoother than GODI.  In addition to having what I
consider to be a better user interface, upgrading of packages in OPAM
has been very smooth overall.  I found upgrades in GODI to be pretty
tricky, with many upgrades ending in failure for one reason or
another.  I suspect this has something to do with the system for
handling of dependencies in OPAM, which has taken quite a bit of work
to get right from what I understand.

In addition, the ability to easily handle multiple compilers in OPAM
is also a big win, from my perspective.  I think it makes it much
easier to try out and give feedback on upcoming compiler versions,
which is good for the community as a whole.  (Plus, trying out
bleeding-edge compiler patches is fun...)

With the arrival of OPAM, for the first time I feel good about
recommending that new users try out libraries with significant
dependencies like Core, since installing such libraries is now really
quite simple.

y

On Sun, Jul 21, 2013 at 10:20 AM, Anil Madhavapeddy <anil@recoil.org> wrote:
> On 21 Jul 2013, at 14:54, "Gerd Stolpmann" <info@gerd-stolpmann.de> wrote:
>>
>>> Hello,
>>> could someone explain please the relation between godi and opam ? Is it
>>> concurrent ?
>>> Godi has been there for some time, and works quite nicely. So what are
>>> differences ?
>>
>> Hi,
>>
>> both are independent projects. OPAM is a younger project, and I don't
>> really know what the motivation behind it is (in addition to the generic
>> motication to hack something). There were initially claims to make it is
>> easier to package software up, but what I've seen is actually not much
>> different from GODI (actually even worse now that GODI allows it to fully
>> automate package releases).
>
> The answer's right there on the front page:
>
> "OPAM is a source-based package manager for OCaml. It supports multiple
> simultaneous compiler installations, flexible package constraints, and a
> Git-friendly development workflow."
>
>> The feature sets are not the same, and some stuff works better in OPAM and
>> some in GODI. As I'm advocating the latter, let me point out some features
>> where I think GODI is better:
>
> Feature minutiae aside, I'd say the biggest benefit of OPAM is the more
> open development workflow. It's easier for people to maintain their
> own branches and contribute changes to the central repository.
>
> Let's look at the stable repository "pulse":
> https://github.com/OCamlPro/opam-repository/pulse/monthly
>
> It tells us that in the last month, there have been 30 authors that have
> pushed 167 package updates. These have all come in as pull requests that
> can still be browsed.  For example, see the latest Core from Jane Street:
> https://github.com/OCamlPro/opam-repository/pulls?state=closed
>
> Several development groups also maintain their own remotes without any
> need to depend on the central repository. For example, see Citrix's:
> https://github.com/xapi-project/opam-repo-dev/tree/master/packages
>
> As Gerd points out, GODI is an older and more mature project. I find
> OPAM more useful for my own personal development workflow though. You
> should try both out and see which one you prefer.
>
> cheers,
> 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: [Caml-list] opam and godi

[Fabrice Le Fessant]

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

Hello,

  Looking only at the number of packages available in the repositories,
Opam has around 400 packages while Godi has around 170 packages. Also, Opam
can use "aspcud" to compute the minimal number of changes when
installing/updating, which can make a big difference when dependency
constraints between packages become hard to solve. I also like the
interface "à la apt-get", compared to the curses interface that I used with
Godi.

--Fabrice

On Fri, Jul 19, 2013 at 7:22 PM, <r.3@libertysurf.fr> wrote:

> Hello,
> could someone explain please the relation between godi and opam ? Is it
> concurrent ?
> Godi has been there for some time, and works quite nicely. So what are
> differences ?
> Thanks,
> William
>

-- 
Fabrice LE FESSANT
Chercheur en Informatique
INRIA Paris Rocquencourt -- OCamlPro
Programming Languages and Distributed Systems

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

Re: [Caml-list] opam and godi

[Matthieu Dubuget]

godi can be used under Windows™. I did not succeed to install opam on a 
windows workstation.

<disclaimer>
Note that I would prefer not having to use Windows
</disclaimer>

Salutations

-- 
Matthieu Dubuget

Re: [Caml-list] opam and godi

[Francois Berenger]

On 07/22/2013 03:55 PM, Fabrice Le Fessant wrote:
> Hello,
>
>    Looking only at the number of packages available in the repositories,
> Opam has around 400 packages while Godi has around 170 packages. Also,
> Opam can use "aspcud" to compute the minimal number of changes when
> installing/updating, which can make a big difference when dependency
> constraints between packages become hard to solve. I also like the
> interface "à la apt-get", compared to the curses interface that I used
> with Godi.

I also like the apt-get/aptitude style of OPAM command lines.

As an impatient user, I also feel that OPAM is way faster than GODI.

> --Fabrice
>
> On Fri, Jul 19, 2013 at 7:22 PM, <r.3@libertysurf.fr
> <mailto:r.3@libertysurf.fr>> wrote:
>
>     Hello,
>     could someone explain please the relation between godi and opam ? Is
>     it concurrent ?
>     Godi has been there for some time, and works quite nicely. So what
>     are differences ?
>     Thanks,
>     William
>
>
> --
> Fabrice LE FESSANT
> Chercheur en Informatique
> INRIA Paris Rocquencourt -- OCamlPro
> Programming Languages and Distributed Systems

Re: [Caml-list] opam and godi

[Adrien Nader]

On Sun, Jul 21, 2013, Yaron Minsky wrote:
> While I appreciate the work that Gerd has done on GODI, I do think
> that OPAM is a significant improvement over GODI.
> 
> From an end-user-experience perspective, I've found OPAM to be
> considerably smoother than GODI.  In addition to having what I
> consider to be a better user interface, upgrading of packages in OPAM
> has been very smooth overall.  I found upgrades in GODI to be pretty
> tricky, with many upgrades ending in failure for one reason or
> another.  I suspect this has something to do with the system for
> handling of dependencies in OPAM, which has taken quite a bit of work
> to get right from what I understand.

I haven't had such issues that were caused by godi itself.

All of the issues I've had were caused by broken sources, packaging or
old ones. I believe the main difference between opam and godi lies in
git as Anil mentionned. By relying on git and taking advantage of its
flexibility, it makes modifying package much easier.

Let's take the example of ocamldsort. It's in godi at version 0.14.1 and
I'd like to see it at version >= 0.15. It seems to me it's only a matter
of bumping the version, everything works the same.
The work involved with GODI for such a small change seems heavier then
with opam (slightly more steps, the need to contact the current package
manager, svn).

It's a slower process but at the same time, it seems to me that almost
all of the updates that get to godi users work well. With opam, I've
seen broken packages more often but at the same time they get fixed more
quickly.

In the end, maybe you have:
- godi, slower package updates but usually more stable; bugs in packages
  are less common but when they exist, they can also take time to fix
- opam, many more updates, maybe too many, packages get less testing
  before they reach others (if you want new software, you can't have a
  week of testing between each release)

NB: don't get me wrong, I don't blame any package maintainer or package
on slow updates or bugs: many issues arise when software is used on 10
different setups (different CPUs, different OS, ....)

> In addition, the ability to easily handle multiple compilers in OPAM
> is also a big win, from my perspective.  I think it makes it much
> easier to try out and give feedback on upcoming compiler versions,
> which is good for the community as a whole.  (Plus, trying out
> bleeding-edge compiler patches is fun...)

Every time I hear this, I'm very surprised: I simply change my PATH
environment variable for the current shell I'm in and get the same
effect
For instance, my shell history has this:
  export PATH=$(echo $PATH | sed
  's;opt/ocaml;home/adrien/projects/ocaml-ty;g')

It's very simple and works even though I haven't installed ocaml-ty
through godi.


PS: Gerd, I believe the "Packager FAQ" needs some pruning. ;-) 

-- 
Adrien Nader

Re: [Caml-list] opam and godi

[Adrien Nader]

On Mon, Jul 22, 2013, Francois Berenger wrote:
> On 07/22/2013 03:55 PM, Fabrice Le Fessant wrote:
> >Hello,
> >
> >   Looking only at the number of packages available in the repositories,
> >Opam has around 400 packages while Godi has around 170 packages. Also,
> >Opam can use "aspcud" to compute the minimal number of changes when
> >installing/updating, which can make a big difference when dependency
> >constraints between packages become hard to solve. I also like the
> >interface "à la apt-get", compared to the curses interface that I used
> >with Godi.
> 
> I also like the apt-get/aptitude style of OPAM command lines.
> 
> As an impatient user, I also feel that OPAM is way faster than GODI.

As far as I can tell, godi_console is now a native-compiled executable
while it used to be byte-compiled before.
This has made it *WAY* faster (at least 5 times faster according to my
testing earlier). I really hated these 10-15 seconds of waiting.

-- 
Adrien Nader

Re: [Caml-list] opam and godi

[Török Edwin]

On 07/21/2013 05:43 PM, Yaron Minsky wrote:
> While I appreciate the work that Gerd has done on GODI, I do think
> that OPAM is a significant improvement over GODI.

I thought I'd share why and how I started using OPAM.

I have used GODI briefly when I had to install some application on RHEL, which had some old version of the OCaml compiler at the time, and missing most of the libraries I needed.
GODI was very smooth to use for that purpose, and I'm glad that someone dedicated time to writing and maintaining it.

My main system is Debian though, and I was quite happy with the OCaml packages provided by the distribution, so I didn't have a reason to use GODI (or another source-based package manager) on Debian.
After OCaml 4.00 got released I eventually needed a source-based package manager, and when OPAM was available I gave it a try. It was fairly simple to use and worked well (except some small issues with upgrades ocasionally), and it is the main package manager I use for OCaml now.

> 
> From an end-user-experience perspective, I've found OPAM to be
> considerably smoother than GODI.  In addition to having what I
> consider to be a better user interface,

opam's simplistic interface is closer to apt-get, which I use and like.
GODI's ncurses-like interface is more like aptitude's curses-interface ... which I don't use.
It also has a command-line interface, which I haven't tried (the docs place little emphasis on it).

So perhaps the less-advanced interface of opam wins exactly because of that.
Or maybe it is because GODI already existed at the time I started learning OCaml, and OPAM is the new tool for me that came much later, and I like it only because I used it more recently.

There is more to OPAM though, 'opam switch' is definitely a useful feature, as is the ability to use the system's OCaml compiler (I may be wrong here, does GODI support that?).

Having said that I would've preferred if OPAM and GODI worked together rather than having a completely new project.
In the end I think what would be best is if OASIS could be automatically converted to OPAM, GODI, DEB and RPM packages, and then upstream projects would only need to worry about supplying one correct _oasis file, and OPAM/GODI could use that directly, so that all build/depedency etc. fixes eventually end up in all repositories.
And of course the conversion shouldn't be one-time only, whenever _oasis is updated the changes should propagate, perhaps with some small addons _oasis.debian, _oasis.opam, etc. for things that cannot be expressed in OASIS directly (or which doesn't make sense to have in _oasis, like name of downstream maintainers).
Packagers should prefer to update these files, instead of their distribution-specific ones, and have the distro-specific build descriptions automatically generated from this.

I'm aware that OASIS is not perfect either (there was a discussion earlier about installing docs), but I think that improving it (and the conversion tools) would eventually get us a simple unified build/package description and then library/application authors and end-users shouldn't care what package manager they use: they'd get a similar quality experience. And whenever a bug is discovered by the user of one package manager, the fix is applied to all.

I'm aware that oasis2deb, oasis2opam exist, does oasis2godi and oasis2rpm exist? How does OASIS-DB fit into this picture?
There is of course the question what to do about packages that do not provide an _oasis file, maybe a start would be opam2oasis (and godi2oasis?) that would provide a dummy _oasis file that just uses the custom Makefiles of the package, but provide all the metadata that the package does.

> upgrading of packages in OPAM
> has been very smooth overall.  I found upgrades in GODI to be pretty
> tricky, with many upgrades ending in failure for one reason or
> another.

I've had OPAM upgrades fail due to bugs in packages / missing system dependencies a few times,
and there is a bug open about support for rollbacks, so it is not as smooth as "apt-get" yet.
I haven't used GODI long enough to be able to compare it with OPAM on this regard.


>  I suspect this has something to do with the system for
> handling of dependencies in OPAM, which has taken quite a bit of work
> to get right from what I understand.
> 
> In addition, the ability to easily handle multiple compilers in OPAM
> is also a big win, from my perspective.  I think it makes it much
> easier to try out and give feedback on upcoming compiler versions,
> which is good for the community as a whole.  (Plus, trying out
> bleeding-edge compiler patches is fun...)

Agreed.

Best regards,
--Edwin

Re: [Caml-list] opam and godi

[Gerd Stolpmann]

> On 07/21/2013 05:43 PM, Yaron Minsky wrote:
>> While I appreciate the work that Gerd has done on GODI, I do think
>> that OPAM is a significant improvement over GODI.

Török Edwin wrote:
> opam's simplistic interface is closer to apt-get, which I use and like.
> GODI's ncurses-like interface is more like aptitude's curses-interface ...
> which I don't use.
> It also has a command-line interface, which I haven't tried (the docs
> place little emphasis on it).

It's not that much different to apt-get.

The curses-like interface is more for beginners, or getting started.

> There is more to OPAM though, 'opam switch' is definitely a useful
> feature, as is the ability to use the system's OCaml compiler (I may be
> wrong here, does GODI support that?).

Partially. You can demand a specific svn version of the compiler, and then
rebuild everything, but it's not wrapped up as command. Maybe something to
add (this would fit well into the framework).

> Having said that I would've preferred if OPAM and GODI worked together
> rather than having a completely new project.
> In the end I think what would be best is if OASIS could be automatically
> converted to OPAM, GODI, DEB and RPM packages, and then upstream projects
> would only need to worry about supplying one correct _oasis file, and
> OPAM/GODI could use that directly, so that all build/depedency etc. fixes
> eventually end up in all repositories.

Fully supporting that.

> And of course the conversion shouldn't be one-time only, whenever _oasis
> is updated the changes should propagate, perhaps with some small addons
> _oasis.debian, _oasis.opam, etc. for things that cannot be expressed in
> OASIS directly (or which doesn't make sense to have in _oasis, like name
> of downstream maintainers).
> Packagers should prefer to update these files, instead of their
> distribution-specific ones, and have the distro-specific build
> descriptions automatically generated from this.
>
> I'm aware that OASIS is not perfect either (there was a discussion earlier
> about installing docs), but I think that improving it (and the conversion
> tools) would eventually get us a simple unified build/package description
> and then library/application authors and end-users shouldn't care what
> package manager they use: they'd get a similar quality experience. And
> whenever a bug is discovered by the user of one package manager, the fix
> is applied to all.
>
> I'm aware that oasis2deb, oasis2opam exist, does oasis2godi and oasis2rpm
> exist?

There is a script for converting oasis to GODI, godi_oasis_import, which
is available now in GODI.

> How does OASIS-DB fit into this picture?

GODI even automatically imports packages from OASIS-DB into its own
repository, with nightly refresh. This is still a bit experimental, and
needs to be activated by the user in order to get the packages (described
here: http://godi.camlcity.org/godi/oasis.html).

The GODI autobuilder also tries to build the oasis packages. See the list
here (scroll down until the package names start with oasis):
https://godirepo.camlcity.org/openapps/autoui.cgi

As you can see, it is only partially successful. That's basically because
there is no QA on OASIS-DB.

> There is of course the question what to do about packages that do not
> provide an _oasis file, maybe a start would be opam2oasis (and
> godi2oasis?) that would provide a dummy _oasis file that just uses the
> custom Makefiles of the package, but provide all the metadata that the
> package does.

No, all package managers should unite in this point, and only accept
packages with oasis support. (Btw, that's homework for me.) Just do it the
same way as we did when requiring findlib.

The question here is whether oasis is already mature enough to require it.


Gerd
-- 
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.

Re: [Caml-list] opam and godi

[Gerd Stolpmann]

> On Mon, Jul 22, 2013, Francois Berenger wrote:
>> On 07/22/2013 03:55 PM, Fabrice Le Fessant wrote:
>> >Hello,
>> >
>> >   Looking only at the number of packages available in the
>> repositories,
>> >Opam has around 400 packages while Godi has around 170 packages. Also,
>> >Opam can use "aspcud" to compute the minimal number of changes when
>> >installing/updating, which can make a big difference when dependency
>> >constraints between packages become hard to solve. I also like the
>> >interface "à la apt-get", compared to the curses interface that I used
>> >with Godi.
>>
>> I also like the apt-get/aptitude style of OPAM command lines.
>>
>> As an impatient user, I also feel that OPAM is way faster than GODI.
>
> As far as I can tell, godi_console is now a native-compiled executable
> while it used to be byte-compiled before.
> This has made it *WAY* faster (at least 5 times faster according to my
> testing earlier). I really hated these 10-15 seconds of waiting.

Actually, this is fixed since I did a performance audit, giving special
attention to such problems. The natively-compiled command has always been
built, but the bug was that it wasn't installed :-(. Also, there is now
better caching of package scanning results.

Gerd
-- 
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.

Re: [Caml-list] opam and godi

[Gerd Stolpmann]

Sad to read such FUD here. The truth is that the company Yaron is working
for never managed to create good Core packages. I don't know what the
reason is, but I guess so it is within this company, since other people
with fewer resources mastered similar tasks well. This is something I was
always puzzled about, since initially there was good cooperation with this
company.

So far I've removed Core from GODI because it misses QA standards, and
have no plans to add it again.

Gerd

Yaron Minsky wrote:
> While I appreciate the work that Gerd has done on GODI, I do think
> that OPAM is a significant improvement over GODI.
>
> From an end-user-experience perspective, I've found OPAM to be
> considerably smoother than GODI.  In addition to having what I
> consider to be a better user interface, upgrading of packages in OPAM
> has been very smooth overall.  I found upgrades in GODI to be pretty
> tricky, with many upgrades ending in failure for one reason or
> another.  I suspect this has something to do with the system for
> handling of dependencies in OPAM, which has taken quite a bit of work
> to get right from what I understand.
>
> In addition, the ability to easily handle multiple compilers in OPAM
> is also a big win, from my perspective.  I think it makes it much
> easier to try out and give feedback on upcoming compiler versions,
> which is good for the community as a whole.  (Plus, trying out
> bleeding-edge compiler patches is fun...)
>
> With the arrival of OPAM, for the first time I feel good about
> recommending that new users try out libraries with significant
> dependencies like Core, since installing such libraries is now really
> quite simple.
>
> y
>
> On Sun, Jul 21, 2013 at 10:20 AM, Anil Madhavapeddy <anil@recoil.org>
> wrote:
>> On 21 Jul 2013, at 14:54, "Gerd Stolpmann" <info@gerd-stolpmann.de>
>> wrote:
>>>
>>>> Hello,
>>>> could someone explain please the relation between godi and opam ? Is
>>>> it
>>>> concurrent ?
>>>> Godi has been there for some time, and works quite nicely. So what are
>>>> differences ?
>>>
>>> Hi,
>>>
>>> both are independent projects. OPAM is a younger project, and I don't
>>> really know what the motivation behind it is (in addition to the
>>> generic
>>> motication to hack something). There were initially claims to make it
>>> is
>>> easier to package software up, but what I've seen is actually not much
>>> different from GODI (actually even worse now that GODI allows it to
>>> fully
>>> automate package releases).
>>
>> The answer's right there on the front page:
>>
>> "OPAM is a source-based package manager for OCaml. It supports multiple
>> simultaneous compiler installations, flexible package constraints, and a
>> Git-friendly development workflow."
>>
>>> The feature sets are not the same, and some stuff works better in OPAM
>>> and
>>> some in GODI. As I'm advocating the latter, let me point out some
>>> features
>>> where I think GODI is better:
>>
>> Feature minutiae aside, I'd say the biggest benefit of OPAM is the more
>> open development workflow. It's easier for people to maintain their
>> own branches and contribute changes to the central repository.
>>
>> Let's look at the stable repository "pulse":
>> https://github.com/OCamlPro/opam-repository/pulse/monthly
>>
>> It tells us that in the last month, there have been 30 authors that have
>> pushed 167 package updates. These have all come in as pull requests that
>> can still be browsed.  For example, see the latest Core from Jane
>> Street:
>> https://github.com/OCamlPro/opam-repository/pulls?state=closed
>>
>> Several development groups also maintain their own remotes without any
>> need to depend on the central repository. For example, see Citrix's:
>> https://github.com/xapi-project/opam-repo-dev/tree/master/packages
>>
>> As Gerd points out, GODI is an older and more mature project. I find
>> OPAM more useful for my own personal development workflow though. You
>> should try both out and see which one you prefer.
>>
>> cheers,
>> 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
>
> --
> 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
>
>


-- 
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.

Re: [Caml-list] opam and godi

[Anil Madhavapeddy]

On 22 Jul 2013, at 08:44, Adrien Nader <adrien@notk.org> wrote:

> In the end, maybe you have:
> - godi, slower package updates but usually more stable; bugs in packages
>  are less common but when they exist, they can also take time to fix
> - opam, many more updates, maybe too many, packages get less testing
>  before they reach others (if you want new software, you can't have a
>  week of testing between each release)
> 
> NB: don't get me wrong, I don't blame any package maintainer or package
> on slow updates or bugs: many issues arise when software is used on 10
> different setups (different CPUs, different OS, ....)

This is absolutely true.  I've been assembling a little machine pool of
'exotic architectures' that make it easier to test all the various 
permutations.  OPAM has a vestigial autobuilder now that runs through a
bunch of different platforms.  For a *temporary* URL with our development
version, see:
https://ocaml-www3.ocamllabs.cl.cam.ac.uk/github/OCamlPro/opam-repository

Once the teething issues are sorted, David Sheets has also written Github
bindings so that work will be queued up directly from a Github pull request.
Anyone submitting a report can have their package tested on systems they
don't normally have access to.  This will in turn let us do acceptance tests
before merging pull requests into the 'stable' OPAM repository.

I really like the Git workflow behind all this.  It basically reflects
how we work with OCaml in an industrial setting: pool up a sequence of
local changes (across multiple repositories), publish them to an internal
OPAM remote, and then issue pull requests upstream until you hit the
central stable repository.  At no point do you have to block waiting for
someone else to do something for you, unless it's the default central
repository that Thomas and I monitor.

I'm also very pleased to announce that Rackspace (who use OCaml via the
Xen Cloud toolstack) have recently donated a significant number of VMs
to power all the builds behind this. We can use this infrastructure to
securely run unit tests: we just need to set up a "gold image" VM with
the build, unplugging its external network interface, run the test,
and then replug it back into the network.  All via HTTP interfaces,
with feedback sent back to the package maintainer via the Github pull
request interface.

-anil

(PS: for those concerned about an over-dependence on Github, I'm currently
evaluating Gitlab, which Jeremy Yallop pointed out to me -- it seems a
good candidate to mirror all this activity somewhere else, while still
using Github as a primary source).

Re: [Caml-list] opam and godi

[David Scott]

On 21/07/13 15:20, Anil Madhavapeddy wrote:
[ snip ]
 > Feature minutiae aside, I'd say the biggest benefit of OPAM is the more
 > open development workflow. It's easier for people to maintain their
 > own branches and contribute changes to the central repository.

[ snip ]

 > Several development groups also maintain their own remotes without any
 > need to depend on the central repository. For example, see Citrix's:
 > https://github.com/xapi-project/opam-repo-dev/tree/master/packages

I really like the git-style development workflow encouraged by OPAM. 
Note I'm not a GODI user so I don't know if the same thing can be done 
there.

The packages you link to above are in development, and having our own 
package repo in git means that we can use pull requests both to propose 
changes to the code, and to quickly update the packages. As each package 
matures, we can then make pull requests to the main OPAM repo.

Lowering the effort needed to create and maintain a package has had 
another useful side-effect (IMHO). Previously while working on 
Xen(Server) we created a few large monolithic libraries which were 
tending (perhaps) towards becoming 'frameworks' (in a bad way). Now 
we've started isolating distinct areas of functionality and chopping 
them off into independently usable libs, or dropping them altogether in 
favour of better alternatives (e.g. we're dropping a custom HTTP server 
library in favour of cohttp). This kind of strong isolation between 
components will make the code easier for us to maintain.

Regarding binary packages: for our use-cases binary package support via 
OPAM or GODI isn't necessary. We'd like to distribute binary packages of 
our software through Linux distributions, which means we're keen to 
create .rpms and .debs in the usual way. Typically our stuff runs as 
services, which means you need to write distro-specific code to 
integrate with systemd/upstart anyway, so there's little an automatic 
tool can do to help.


Cheers,
Dave Scott
XenServer System Architect, Citrix

Re: [Caml-list] opam and godi

[Yaron Minsky]

Sigh.  I don't mean to get into a fight.  And the problems I've run
into with GODI, though, had nothing to do with the Core packages, so
that seems a bit off topic.

GODI surely has its uses, and in particular the Windows support is a
nice thing that OPAM still lacks.  That said, I very much prefer OPAM
(for the reasons echoed by others), and there's little doubt in my
mind as to which package manager I recommend to people who are working
on a UNIX or Mac platform.

y

On Mon, Jul 22, 2013 at 8:55 AM, Gerd Stolpmann  wrote:
> Sad to read such FUD here. The truth is that the company Yaron is working
> for never managed to create good Core packages. I don't know what the
> reason is, but I guess so it is within this company, since other people
> with fewer resources mastered similar tasks well. This is something I was
> always puzzled about, since initially there was good cooperation with this
> company.
>
> So far I've removed Core from GODI because it misses QA standards, and
> have no plans to add it again.
>
> Gerd
>
> Yaron Minsky wrote:
>> While I appreciate the work that Gerd has done on GODI, I do think
>> that OPAM is a significant improvement over GODI.
>>
>> From an end-user-experience perspective, I've found OPAM to be
>> considerably smoother than GODI.  In addition to having what I
>> consider to be a better user interface, upgrading of packages in OPAM
>> has been very smooth overall.  I found upgrades in GODI to be pretty
>> tricky, with many upgrades ending in failure for one reason or
>> another.  I suspect this has something to do with the system for
>> handling of dependencies in OPAM, which has taken quite a bit of work
>> to get right from what I understand.
>>
>> In addition, the ability to easily handle multiple compilers in OPAM
>> is also a big win, from my perspective.  I think it makes it much
>> easier to try out and give feedback on upcoming compiler versions,
>> which is good for the community as a whole.  (Plus, trying out
>> bleeding-edge compiler patches is fun...)
>>
>> With the arrival of OPAM, for the first time I feel good about
>> recommending that new users try out libraries with significant
>> dependencies like Core, since installing such libraries is now really
>> quite simple.
>>
>> y
>>
>> On Sun, Jul 21, 2013 at 10:20 AM, Anil Madhavapeddy
>> wrote:
>>> On 21 Jul 2013, at 14:54, "Gerd Stolpmann"
>>> wrote:
>>>>
>>>>> Hello,
>>>>> could someone explain please the relation between godi and opam ? Is
>>>>> it
>>>>> concurrent ?
>>>>> Godi has been there for some time, and works quite nicely. So what are
>>>>> differences ?
>>>>
>>>> Hi,
>>>>
>>>> both are independent projects. OPAM is a younger project, and I don't
>>>> really know what the motivation behind it is (in addition to the
>>>> generic
>>>> motication to hack something). There were initially claims to make it
>>>> is
>>>> easier to package software up, but what I've seen is actually not much
>>>> different from GODI (actually even worse now that GODI allows it to
>>>> fully
>>>> automate package releases).
>>>
>>> The answer's right there on the front page:
>>>
>>> "OPAM is a source-based package manager for OCaml. It supports multiple
>>> simultaneous compiler installations, flexible package constraints, and a
>>> Git-friendly development workflow."
>>>
>>>> The feature sets are not the same, and some stuff works better in OPAM
>>>> and
>>>> some in GODI. As I'm advocating the latter, let me point out some
>>>> features
>>>> where I think GODI is better:
>>>
>>> Feature minutiae aside, I'd say the biggest benefit of OPAM is the more
>>> open development workflow. It's easier for people to maintain their
>>> own branches and contribute changes to the central repository.
>>>
>>> Let's look at the stable repository "pulse":
>>> https://github.com/OCamlPro/opam-repository/pulse/monthly
>>>
>>> It tells us that in the last month, there have been 30 authors that have
>>> pushed 167 package updates. These have all come in as pull requests that
>>> can still be browsed.  For example, see the latest Core from Jane
>>> Street:
>>> https://github.com/OCamlPro/opam-repository/pulls?state=closed
>>>
>>> Several development groups also maintain their own remotes without any
>>> need to depend on the central repository. For example, see Citrix's:
>>> https://github.com/xapi-project/opam-repo-dev/tree/master/packages
>>>
>>> As Gerd points out, GODI is an older and more mature project. I find
>>> OPAM more useful for my own personal development workflow though. You
>>> should try both out and see which one you prefer.
>>>
>>> cheers,
>>> 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
>>
>> --
>> 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
>>
>>
>
>
> --
> Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
> Creator of GODI and camlcity.org.
> Contact details:        http://www.camlcity.org/contact.html
> Company homepage:       http://www.gerd-stolpmann.de
> *** Searching for new projects! Need consulting for system
> *** programming in Ocaml? Gerd Stolpmann can help you.
>