caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Ivan Gotovchits <ivg@ieee.org>
To: Jeremie Dimino <jdimino@janestreet.com>
Cc: "ocaml-core@googlegroups.com" <ocaml-core@googlegroups.com>,
	"caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] Package renamings for sexplib, bin_prot and a few other camlp4 syntax extensions
Date: Tue, 26 Jan 2016 10:15:02 -0500	[thread overview]
Message-ID: <CALdWJ+wUTKG7oanm4R7wsdjyRGGTvAd98NxHXH4Q-4cuV87nzQ@mail.gmail.com> (raw)
In-Reply-To: <CANhEzE7e+A6-s8tJS6SJdoKJ+Ck9boc0Wg02iJVN00ovEXeZMA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2466 bytes --]

> Do you know of any tool that rely on this?

OASIS it the most notable [1].

> ​The '.syntax' names are gone. I thought about keeping them as aliases,
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/MyOCamlbuildFindlib.ml#L161

On Tue, Jan 26, 2016 at 9:50 AM, Jeremie Dimino <jdimino@janestreet.com>
wrote:

> On Tue, Jan 26, 2016 at 1:57 PM, Ivan Gotovchits <ivg@ieee.org> 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?
>>
>
> ​The '.syntax' names are gone. I thought about keeping them as aliases,
> 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
>

[-- Attachment #2: Type: text/html, Size: 4127 bytes --]

  reply	other threads:[~2016-01-26 15:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-26 10:44 Jeremie Dimino
2016-01-26 13:57 ` Ivan Gotovchits
2016-01-26 14:50   ` Jeremie Dimino
2016-01-26 15:15     ` Ivan Gotovchits [this message]
2016-01-26 16:15       ` Jeremie Dimino
2016-01-26 16:56         ` Ivan Gotovchits
2016-01-26 17:17           ` Jeremie Dimino
2016-02-03 10:37             ` Jeremie Dimino
2016-02-03 19:20 ` ygrek
2016-02-05  9:36   ` Jeremie Dimino
2016-03-09 15:56     ` Junsong Li
2016-03-09 16:06       ` Jeremie Dimino
2016-03-09 16:23         ` Junsong Li
2016-03-09 17:16       ` Ivan Gotovchits
2016-03-09 17:31         ` Junsong Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALdWJ+wUTKG7oanm4R7wsdjyRGGTvAd98NxHXH4Q-4cuV87nzQ@mail.gmail.com \
    --to=ivg@ieee.org \
    --cc=caml-list@inria.fr \
    --cc=jdimino@janestreet.com \
    --cc=ocaml-core@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).