<div dir="ltr"><div><div><div>I initially sent it to Gerd Stolpmann on the idea that there may be non-opam users out there for which it would be a good distribution channel. The idea came from the fact that ocamlfind already had all those base-* packages, and that base-bytes was a nice extension of this principle.<br><br></div>It has since been pointed out that this is inconvenient for people that do not use ocamlfind. My own base-bytes implementation is available independently from ocamlfind at<br><br>  <a href="https://github.com/gasche/bytes-compat" target="_blank">https://github.com/gasche/bytes-compat</a><br></div><br>and I know that others have (partially) reimplemented this, e.g. Pierre Chambart's ocaml-bytes:<br><br>  <a href="https://github.com/chambart/ocaml-bytes" target="_blank">https://github.com/chambart/ocaml-bytes</a><br><br></div><div>(I now realize that there is no license on my separate bytes-compat package; it should be BSD or whatever -- inside findlib it is distributed with findlib's license, which is the MIT license.)<br></div><div><br></div><div>I have no strong opinion on where such compatibility packages should go, and I think (as we both pointed out) that it would be important to have a consistent process for those things. If you or someone else are willing to give clear directives on how to go forward with compatibility packages, I think it could be really nice. In particular, is there a way to avoid a combinatorial explosion of small compatibility packages, or is this ok for users?<br><br></div><div>(Batteries provides back-ported implementation of new stdlib features, so using Batteries removes the need for such backward-compatibility packages. A more general and less invasive solution would still be very nice.)<br><br></div><div>I think that for the specifics of this package and ocamlfind, you would have to see directly with Gerd Stolpmann if you want to move it out.<br><br>There is also the question of what the responsibility of this package is. The initial plan was to provide only the features available at the time Bytes was introduced (4.02), but I think it could be nice to add new functions to keep up with recent stdlib versions of Bytes. This could be done as a separate package, but it can also be done in findlib. In my experience Gerd has been very responsive in updating the bytes implementation during the 4.02+dev development period, and this may be even easier now that he switched to git repositories<br><br>  <a href="https://gitlab.camlcity.org/gerd/lib-findlib" target="_blank">https://gitlab.camlcity.org/gerd/lib-findlib</a><br><br></div><div>If we decide to update the bytes package, we have to decide on a versioning scheme. The simplest may be to have base-bytes version follow upstream OCaml version, so that people can request<br><br>  base-bytes {>= 4.03}<br><br>if they use a Bytes feature only available since 4.03.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 25, 2016 at 12:35 PM, Daniel Bünzli <span dir="ltr"><<a href="mailto:daniel.buenzli@erratique.ch" target="_blank">daniel.buenzli@erratique.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It strikes me as odd that the bytes compatibility package was integrated in ocamlfind.<br>
<br>
I'm not sure I understand the rationale behind this move, it obscures things rather than enlight them.<br>
<br>
I think we should move it out from there as a separate package and follow the conventions established by the `result` and `uchar` compatibility packages.<br>
<br>
Or is there anything that I am missing ?<br>
<br>
Best,<br>
<br>
Daniel<br>
<br>
<br>
_______________________________________________<br>
Platform mailing list<br>
<a href="mailto:Platform@lists.ocaml.org" target="_blank">Platform@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/platform" rel="noreferrer" target="_blank">http://lists.ocaml.org/listinfo/platform</a><br>
</blockquote></div><br></div></div>