From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id B68F87FDE8 for ; Tue, 26 Jan 2016 16:15:04 +0100 (CET) IronPort-PHdr: 9a23:eAkpphIpd21QkBjfFtmcpTZWNBhigK39O0sv0rFitYgULfnxwZ3uMQTl6Ol3ixeRBMOAu60C07Kd7viocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWC0ILvj6vvo9X6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFmrPHs4DvOVwaK53ZUfmQTkxxPS1zH4BD/X5H2minzsOdmxDOXMNGwRrcxD2eM9aBuHT72gSFPGDkl93/cis1sl+oPoQyujx1yzoOSZ5uaYqktNpjBdM8XEDISFv1aUDZMV8blN9MC Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=ivg@ieee.org; spf=Pass smtp.mailfrom=ivg@ieee.org; spf=None smtp.helo=postmaster@mail-lf0-f41.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of ivg@ieee.org) identity=pra; client-ip=209.85.215.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of ivg@ieee.org designates 209.85.215.41 as permitted sender) identity=mailfrom; client-ip=209.85.215.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-lf0-f41.google.com) identity=helo; client-ip=209.85.215.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="postmaster@mail-lf0-f41.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CAAQBWjKdWmynXVdFehAxtBohRtAskhSFKAoE9BzwQAQEBAQEBAQEQAQEBAQEGCwsJIS6CLYIUAQEBAwESER0BATcBBAsLCwMKKgICIhIBBQEcBhMih3EIDqFagTE+MYpNZ4RAAQSKYwEBAQEBAQEDAQEBAQEBAQESAgQKhiiEbYJnghGCVIE6jTJ0iFiFRoJyBYUZgV6NG0SFLocUER+BDTeCHw0RBxuBUx4uAYhDAQEB X-IPAS-Result: A0CAAQBWjKdWmynXVdFehAxtBohRtAskhSFKAoE9BzwQAQEBAQEBAQEQAQEBAQEGCwsJIS6CLYIUAQEBAwESER0BATcBBAsLCwMKKgICIhIBBQEcBhMih3EIDqFagTE+MYpNZ4RAAQSKYwEBAQEBAQEDAQEBAQEBAQESAgQKhiiEbYJnghGCVIE6jTJ0iFiFRoJyBYUZgV6NG0SFLocUER+BDTeCHw0RBxuBUx4uAYhDAQEB X-IronPort-AV: E=Sophos;i="5.22,350,1449529200"; d="scan'208,217";a="161714781" Received: from mail-lf0-f41.google.com ([209.85.215.41]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 26 Jan 2016 16:15:03 +0100 Received: by mail-lf0-f41.google.com with SMTP id c192so106871453lfe.2 for ; Tue, 26 Jan 2016 07:15:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qzrZXqv10niFZS+m/2sEIIdolqnGyBZMtWORXFI+amc=; b=Wg1DQdGqtQSGbT1JHIbu6R5WkShghdJqAY5lqZ2XqN7qR6GzK55nRlhPUeJKBshoKN SsoW2X5VPrRTwjpXvmjhp1fxZPLeamMLZlU07i7CM/HtxL1C75EmpIZSVQI+24DtDuqB nvIqef59e13m6sTdo4pH02Vt+exryBWr2hSY831Fy1G2C1BW+sW188/Nbb8yz3YBZ0es woclsseG6LQEqeygt3ryBcaDQALWoiRyV5VTyNZjQZPaZwycu+i/WQDeL04cvQTHhO2Q wE04jdO3Uc9yxOfhQUEgxJ7i7lsufmBk0pHtuasN3poJzNH0ThKh9Ht/f9AJRxOMUF2w QSjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qzrZXqv10niFZS+m/2sEIIdolqnGyBZMtWORXFI+amc=; b=ey/gGKkusA4SGwj60rCx6OyzTYTFrjhimB6dgTeLG9CvSrwnxKtbwVIgRht6h/h4WA saS5PcbitX/e1M48dGrcxJ6R9W/Sa+3GEaw+qr3WGBHKV6JZ7YSGulUkgodAW57UZXne EtwcZ8fmzuqNBzjlocwoCNf9u9QGW+DD3eFdpVLyJfcZ85vbm7VUkHf4FDRrhkn4pwXh Wm1eDbPQ4Jv9vqvU1d0LWTqjKWubq+F7DP+Ca1qJc8N7tYU9SD7yl7P0fHCEeaDXwPT6 UYIdHE+rv0e4/kzpnNjzoM1xgMiqHUzFlNl2MaopyQfCmtCcBGWLf1GdHQ6wLOKXntP4 qPzA== X-Gm-Message-State: AG10YOSIUsUB18tiQ6V1PEVq48FwOKyiTJBwB92CJH9hTIaJ4nddURZb7HjAMzgUhAhnYzBsJdi5RjXT/MOWmsZt MIME-Version: 1.0 X-Received: by 10.25.160.1 with SMTP id j1mr9295525lfe.35.1453821302703; Tue, 26 Jan 2016 07:15:02 -0800 (PST) Received: by 10.114.183.52 with HTTP; Tue, 26 Jan 2016 07:15:02 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Jan 2016 10:15:02 -0500 Message-ID: From: Ivan Gotovchits To: Jeremie Dimino Cc: "ocaml-core@googlegroups.com" , "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=001a114021f650b64f052a3e260a Subject: Re: [Caml-list] Package renamings for sexplib, bin_prot and a few other camlp4 syntax extensions --001a114021f650b64f052a3e260a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Do you know of any tool that rely on this? OASIS it the most notable [1]. > =E2=80=8BThe '.syntax' names are gone. I thought about keeping them as al= iases, but eventually they'll go away and this split already breaks opam dependencies, so it's simpler to just do the full upgrade right now. Usually, when you release something, you shouldn't change it. The releasing is a process of fixing things in time. Changing a name of library is the same as changing the library. And consider the following example, suppose a released project.0.3 uses one of the removed syntax packages. Ok, you will fix the opam file, and a correct set of dependencies will be installed after an update, but the package build system will still contain hardcoded old names (in _oasis, Makefile, etc). So what should a package maintainer do? I see two options. 1. Delete `project.0.3` from the repository and add new `project.0.3-???` with a fixed build system 2. Retrospectively modify `project.0.3` build system and upload a new tarball without changing a library. The second option will break an expected assumption, that library `project.0.3` should always be the same in time. The first option is not an option also. Also, some packages, may encode library names in the code itself. For example, bap uses this to track dependencies of dynamically loaded plugins. Merlin has a heuristics, that guesses requested syntax extensions based on package names. [1]: https://github.com/ocaml/oasis/blob/master/src/plugins/ocamlbuild/MyOCamlbu= ildFindlib.ml#L161 On Tue, Jan 26, 2016 at 9:50 AM, Jeremie Dimino wrote: > On Tue, Jan 26, 2016 at 1:57 PM, Ivan Gotovchits wrote: > >> I hope that the change will not modify library names retrospectively? >> I.e., the old versions will be still available under the `.syntax` names? >> > > =E2=80=8BThe '.syntax' names are gone. I thought about keeping them as al= iases, > but eventually they'll go away and this split already breaks opam > dependencies, so it's simpler to just do the full upgrade right now. > > Also, presumably some tools rely on the `.syntax` extension, maybe it is >> better to preserve the extension, i.e., to use `pa_sexp_conv.syntax`? >> > > So far we only did this for syntax extensions with a runtime part. For > instance type_conv doesn't have a .syntax package. Do you know of any tool > that rely on this? > > -- > Jeremie > --001a114021f650b64f052a3e260a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> Do you know of any tool that rely on this?
=

OASIS it the most notable [1].=C2=A0

> =E2=80=8BThe '.syntax' names are gone. I thought about keepi= ng them as aliases, but eventually they'll go away and this split alrea= dy breaks opam dependencies, so it's simpler to just do the full upgrad= e right now.

Usually, when you release something, yo= u shouldn't change it. The releasing is a process of fixing things in t= ime. Changing a name of library is the same as changing the library.=C2=A0<= /div>

And consider the following example, suppose a rele= ased project.0.3 uses one of the removed syntax packages. Ok, you will fix = the opam file, and a correct set of dependencies will be installed after an= update,
but the package build system will still contain hardcode= d old names (in _oasis, Makefile, etc). So what should a package maintainer= do? I see two options.=C2=A0

1. Delete `project.0= .3` from the repository and add new `project.0.3-???` with a fixed build sy= stem
2. Retrospectively modify `project.0.3` build system and upl= oad a new tarball without changing a library.

The = second option will break an expected assumption, that library `project.0.3`= should always be the same in time. The first option is not an option also.= =C2=A0

Also, some packages, may encode library nam= es in the code itself. For example, bap uses this to track dependencies of = dynamically loaded plugins. Merlin has a heuristics, that
guesses= requested syntax extensions based on package names.=C2=A0


On Tue, = Jan 26, 2016 at 9:50 AM, Jeremie Dimino <jdimino@janestreet.com&g= t; wrote:
On Tue, Jan 26, 2= 016 at 1:57 PM, Ivan Gotovchits <= ivg@ieee.org> wr= ote:
I hope that the change will not modify library names retrospectively? I.e= ., the old versions will be still available under the `.syntax` names?

=E2=80=8BT= he '.syntax' names are gone. I thought about keeping them as aliase= s, but eventually they'll go away and this split already breaks opam de= pendencies, so it's simpler to just do the full upgrade right now.

Also, presumably some tools rely on the `.syntax` extensio= n, maybe it is better to preserve the extension, i.e., to use `pa_sexp_conv= .syntax`?
<= br>
So far we only did this for syntax extensions with a runtime pa= rt. For instance type_conv doesn't have a .syntax package. Do you know = of any tool that rely on this?

--=C2=A0
Jeremie

--001a114021f650b64f052a3e260a--