Re: On module distribution

[Sylvain Le Gall <sylvain@le-gall.net>]

On 15-01-2008, Bünzli Daniel <daniel.buenzli@erratique.ch> wrote:
> Le 15 janv. 08 à 14:38, Berke Durak a écrit :
>
>> I think we should rather add to Ocamlbuild a module for calling  
>> ocamlfind, parsing its output, etc. This way ocamlbuild plugins  
>> could easily call ocamlfind, be it for configuration or compilation.
>
> My problem with ocamlfind is that it takes too much control over me.  
> Also it doesn't help you with the tedious publishing aspect (which I  
> try to mitigate by using news feeds) and it won't help you with the  
> binary update problem.
>
> Le 15 janv. 08 à 16:07, Sylvain Le Gall a écrit :
>
>> Unfortunately, a decentralized system has also several drawbacks:
> [...]
>
> Yes of course. But the point is that we already have a decentralized  
> system. All these tarballs that are referenced from the hump and not  
> part of godi. My aim is to be able to quickly install or publish such  
> decentralized bits. Currently these two tasks take too much time:  
> using them, because everyone does it its own way, publishing them,  
> because you have to devise your own way (make a readme, think about  
> how to structure the tarball how to manage releases, announce on the  
> mailing list, etc.). The idea is to simplify all this uninteresting  
> business to entice people to share their modules. Lowering the bar may  
> mean a decrease in quality but in the end good modules and reliable  
> publishers will be identified by the community.
>
> Also note that the proposal in itself doesn't prevent the development  
> of a more authoritative, centralized and stable source of packages.
>

I think one of the best way to manage the bazaar is to follow the track
of some other major languages (let say Perl) that has implemented a
standard way to publish project with a good naming scheme et al (let
say CPAN). 

My point is that unfortunately managing the bazaar of OCaml require more
standard procedure and knowledge foreach member of the community. You
will never reach the 100% compliance for every bits of the humps. If you
get something like 10% it will already be something great (i really
think it). 

As in debian, you need to have some kind of required knowledge to begin
publishing good project. You cannot speed up this step.

BUT after having this standard common knowledge that leads to an uniform
packaging, you will be able to perform the second task: using them
quickly...

FYI, i recommend you to browse a little bit about Perl/CPAN, this is
a great work about a centralized module publishing system:
http://pause.perl.org
 
Extract, to show you what mean a required basic knowledge:
[quote]
Your duties, the basics, traps

We trust that you have read the perlmodinstall, perlmodlib,
perlmodstyle, and perlnewmod manpages and that you regularly check out
uploads to CPAN and that you have been watching CPAN activities for a
while to have an impression of how things fit together. It usually boils
down to (slogan shamelessly stolen and adapted from sudo(1)):

   1. Think, better even talk before you upload
   2. Respect the namespace of others
[/quote]

In particular perlmodstyle, perlmodlid and perlmodinstall are really a
good way to understand years of publishing...

>>> 3. Manage packages per project (vs. per machine) to make project
>>> dependencies explicit. Thus a single command can install you the
>>> (OCaml + C stubs only) dependencies of your project on a fresh  
>>> system.
>>> If your project is a package itself, it facilitates its packaging .
>>>
>>
>> I don't agree project and package are not the same thing. You should
>> take into consideration that different distribution have different
>> packaging policy.
>
> That's not what I say. The _if_ of the last sentence is for when you  
> are developing an ocaml library with dependencies in that case your  
> project may become a package. If you are making an end-user  
> application this should not be used as a distribution mechanism, I  
> explicitly say that in the proposal, it is a tool for ocaml  
> _developers_. But still from a developer perspective it is a good  
> thing to have a mechanical way to track the external dependencies of  
> your project whether this is an end-user application or not, hence  
> packages should be (conceptually) managed per project.
>

OK, sorry i don't have understand what you have written. 

Regards,
Sylvain Le Gall