Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[OSR] Ports-like package management system
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Vlad Skvortsov <vss@7...>
Subject: Re: [Caml-list] Re: [OSR] Ports-like package management system
Sylvain Le Gall wrote:
>>>> When you develop a program P you will have use programs P_{i1}, P_{i2}, 
>>>> ... and thus have checkouts of repositories S_{i1}, S_{i2}, and so on. 
>>>> If you find a bug in P_{i1} you can directly edit the checked out 
>>>> version, recompile everything automatically by launching ocaml in P's 
>>>> directory and thus debug P_{i1}.  You can then locally commit your 
>>>> changes to P_{i1} and then easily push the patch or send the diff to the 
>>>> upstream author.
>>> Send a patch to author of P_{i1}. This is the easiest way. 
>>> <hint>
>>> diff -Nurd  P_{i1} P_{i1}.new
>>> </hint>
>> So you need to get a separate copy of P_{i1}, unpack it, and run a diff 
>> by hand...  And what will happen during the process of developing the 
>> patch?  You will be working on your patch without version control 
>> system.  Which is very uncomfortable, especially as you will be working 
>> on unfamiliar code - you will make mistakes, erase or modify important 
>> stuff, won't be able to easily rollback, branch or review your changes.
>> You will have to play around with tar, diff, patch and merge by hand, 
>> make mistakes and create a mess.  Any VCS can handle all these tasks easily.
>> Unless your correction is very minor, you will have to either (a) import 
>> the project into your own favorite VCS, losing history and create a 
>> short-lived repository or be forced to track all future changes by hand; 
>> or (b) checkout the sources using the VCS the authors use - but then 
>> we're back at case one: you will have to potentially have all the 
>> version control systems used by all the software components you may want 
>> to contribute to, and also learn how to use them all.
> You are mixing software development and packaging. If you really want to
> have something clean, you should avoid having changes into the source of
> the upstream author (at least changes that should last).

I agree with this. The lower the entry barrier for the system, the 
better. The simplier the system, the better.

I wouldn't use a system that forces me to install a new sexy VCS on N of 
my machines and learn a new workflow just to use some packaged module.

My strong preference is that any package should be available for 
download via HTTP/FTP. The metadata (central package registry) can be 
versioned or not, I don't care, as long as I can publish my package with 
a single command.

I really like the way it's done in Python, here is a link to my previous 
email on this topic:

Vlad Skvortsov,,