Re: [Caml-list] Re: oasis packaging questions

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

Hi,

2012/3/8 Daniel Bünzli <daniel.buenzli@erratique.ch>:
> Le jeudi, 8 mars 2012 à 09:31, Sylvain Le Gall a écrit :
>> The main change of .cmo -> .cma is that toplevel expression are only
>> evaluated if you open the module.
>
>
> open, like the construct, I thought open was just about syntax ? You mean use or invoke a function ?
>
>> This can be a problem if your .cmo are
>> used in a plugin way (i.e. toplevel expression register the content of
>> your library) and that you don't open it.
>

I think you need to use the function "X.foo" to cause the evaluation
of toplevel statements. But it is something that need to be checked.

>
> Nevertheless I think it's best for users to avoid the change. Is that Object section still due for 0.3 ? Otherwise is there a way to hack around ?
>

I don't think I'll be able to integrate the Object section in 0.3. I
am really planning to release it soon. I just had a quick look at your
git repository and I don't think there will be a difference for user
if it is a .cma (as long as they use ocamlfind).

>> setup.ml will be enough for me ;-) But I am biased.
>
> For distribution, I'm fine with that aswell. For developement setup.ml takes too much time to invoke (adds an overhead of 0.5s on my system).
>

That the parsing time because the file is big. I know this issue and
will try to improve that in the future. I think a 50% down size is
possible, that will bring this time to 250ms. Although, I don't think
that even for development env a 500ms delay is that big... I doubt to
be able to reduce to ~0s.

>> > 4) I'm really not interested in oasis trying to generate my _tags and myocamlbuild.ml files. Is it ok to substitute my own or does setup.ml rely on these ?
>>
>> You can substitute your own. There should be no problem. Don't hesitate
>> to open a feature request to explain the reason why and your solution. I
>> don't promise it will be implemented, but it is worth understanding the
>> reason.
>
>
> First, all my modules don't need an myocamlbuild.ml, second since ocaml 3.12 it is now very easy to express findlib dependencies in _tags files. Third, I don't want to have to sweep through hundreds of generated lines of code (458 for myocamlbuild.ml) of useless configuration stuff when something goes wrong. Avoid bureaucracy at all costs.
>

Never try autoconf ;-)

>> We already discuss this CHANGES file stuff. I still didn't have the time
>>
>> to work on that, but it is something that I want. In future version
>> there should be something like that.
>>
>> Use 'PostCleanCommand: rm XYZ'
>>
>> DataFiles should do that.
>
> You may not have the tarball anymore when you want to uninstall things. That's certainly not a good approach.
>

I suppose you where talking about "make clean", I read too fast, this
is a different issue (ocamlfind remove), which is more a packaging
question (i.e. to the odb/GODI level).

>> Concerning installing this using ocamlfind, I
>> am a little more skeptical. We use standard cp to install in
>> /usr/share/doc. I don't know a lot of libraries that install their
>> documentation in /usr/lib, probably because there are packaging rules
>> against that.
>
>
> I completely disagree with that. I think we already had this discussion. This monolithic view may be suitable for system level packaging system like debian. But I think its wrong to take this approach here. What I need as a developer, is an ocaml specific packaging system that is able to move much quicker than the system level package system and if possible in which you also may install more than one version of a library.
>
> The only clean approach that seems to work well when you want that is that every package installs in its own (versioned) prefix and symlink *if needed* in the regular system directories (see gnu stow, gobolinux or homebrew on osx). It also makes it *damn simple* to understand who installs what and to hack and understand the system when it breaks.
>
> For me helping downstream packaging should not be the first goal of a system like oasis. From my developer's point of view downstream packaging is only usefull to help you to install the base (the language and the language specific package system) and then you should install what you need by using the language specific package system. Here again I think homebrew takes the right approach, they don't repackage any gem, python egg or perl module, they piggyback on the strength of these individual system and let the developers manage them letting them resort to homebrew only when they need dependencies that are outside the scope of the language specific system (C libraries etc.).
>
> So my proposal would be to let ocamlfind manage all that and agree on a few directories. I'm not proficient enough in ocamlfind but I guess it won't be able to support multiple versions. But at least if we can be sure that `ocamlfind remove <pkg>`, removes everything a package installed, documentation included it would be nice. For me it would be enough to stick the CHANGES, README right into ocamlfind's package directories.
>
> $SITELIB/<pkg>/META
> $SITELIB/<pkg>/_oasis
> $SITELIB/<pkg>/README
> $SITELIB/<pkg>/CHANGES
> $SITELIB/<pkg>/share/html/*.html
> $SITELIB/<pkg>/share/examples/
> etc.
>
> Having standard like this could also help efforts like typerex (or even ocamlfind) to know where to lookup for documentation data. Now oasis is the place to enforce such a standard.
>

OK, so first of all you are talking about the odb/GODI/oasis-db level.
OASIS itself is not meant to handle that directly. There will be a
plugin "oasis-db" that will allow you to do "oasis install xmlm" and
"oasis uninstalll xmlm" and fetch the source from
http://oasis.ocamlcore.org but this is the future and this won't be
the core oasis system. You can have a look at odb that allow you to
already do that after having uploaded your package to
http://oasis.ocamlcore.org.

Concerning the ocamlfind install + documentation. I understand you but
it is technically not feasible right now (AFAIK). Simple fact:
ocamlfind cannot install files in subdirectories.

>> That is a bug. I have similar problem with the Pack: when generating
>> _tags with capitalized module name. I installed ocaml on a mac yesterday
>> to find the right solution. It will be shipped with oais 0.3.0~rc3. But
>> this part of the bug is not extremly important, because on case
>> sensitive FS, it will replace the capitalize module name by the right
>> name. It is a runtime evaluation so no worries on this point.
>
> Well I'm not sure I follow your explanation. Wild guessing I suspect you derive the file name from the Modules: key and just try different spellings until a Sys.file_exists returns true. But if you first try with a lowercase you'll always get a true on a case insensitive file system even if the actual file starts with an uppercase, and vice versa so the problem seems insoluble that way, I see no other solution than Sys.readdir the build directory and look for the correct spelling in there. Note it's a real problem if you want the tool to be a good unix citizen, for example diffing d1 and d2 with d1/a.ml and d2/A.ml, will report a.ml and A.ml as being different even if you are on a case insensitive file system. Btw. the standard still seems to have lowercased files module files (witness the whole ocaml system itself), in fact I thought this was mandated by the compilers (don't know were I got that), so in any case using lowercase first may be a better approximation.
>

You understand well, I agree on the fact that lowercase is probably
better. The solution you describe is also the one I will use. For a
Linux guy, this is however not obvious (case insensitive filesystem is
quite uncommon on Linux).

Cheers
Sylvain