* Re: [Caml-list] opam and godi
2013-07-21 14:43 ` Yaron Minsky
@ 2013-07-22 7:44 ` Adrien Nader
2013-07-22 13:30 ` Anil Madhavapeddy
2013-07-22 8:06 ` Török Edwin
2013-07-22 12:55 ` Gerd Stolpmann
2 siblings, 1 reply; 18+ messages in thread
From: Adrien Nader @ 2013-07-22 7:44 UTC (permalink / raw)
To: caml-list
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Caml-list] opam and godi
2013-07-22 7:44 ` Adrien Nader
@ 2013-07-22 13:30 ` Anil Madhavapeddy
0 siblings, 0 replies; 18+ messages in thread
From: Anil Madhavapeddy @ 2013-07-22 13:30 UTC (permalink / raw)
To: Adrien Nader; +Cc: caml-list, opam-devel
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).
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Caml-list] opam and godi
2013-07-21 14:43 ` Yaron Minsky
2013-07-22 7:44 ` Adrien Nader
@ 2013-07-22 8:06 ` Török Edwin
2013-07-22 12:20 ` Gerd Stolpmann
2013-07-22 12:55 ` Gerd Stolpmann
2 siblings, 1 reply; 18+ messages in thread
From: Török Edwin @ 2013-07-22 8:06 UTC (permalink / raw)
To: caml-list
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Caml-list] opam and godi
2013-07-22 8:06 ` Török Edwin
@ 2013-07-22 12:20 ` Gerd Stolpmann
0 siblings, 0 replies; 18+ messages in thread
From: Gerd Stolpmann @ 2013-07-22 12:20 UTC (permalink / raw)
To: "Török Edwin"; +Cc: caml-list
> 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Caml-list] opam and godi
2013-07-21 14:43 ` Yaron Minsky
2013-07-22 7:44 ` Adrien Nader
2013-07-22 8:06 ` Török Edwin
@ 2013-07-22 12:55 ` Gerd Stolpmann
2013-07-22 18:30 ` Yaron Minsky
2 siblings, 1 reply; 18+ messages in thread
From: Gerd Stolpmann @ 2013-07-22 12:55 UTC (permalink / raw)
To: Yaron Minsky; +Cc: Anil Madhavapeddy, r.3, caml-list
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Caml-list] opam and godi
2013-07-22 12:55 ` Gerd Stolpmann
@ 2013-07-22 18:30 ` Yaron Minsky
0 siblings, 0 replies; 18+ messages in thread
From: Yaron Minsky @ 2013-07-22 18:30 UTC (permalink / raw)
To: Gerd Stolpmann; +Cc: Anil Madhavapeddy, r.3, caml-list
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.
>
^ permalink raw reply [flat|nested] 18+ messages in thread