[opam-devel] On the new mixed mode pins

Louis Gesbert louis.gesbert at ocamlpro.com
Wed May 20 03:18:15 BST 2015


> What I understand here is that `opam pin add PATH` should default to some form of path pinning. I have no problem with this (being constrained by the "no magic rule").  

Indeed -- but then it's fair to consider mixed mode as "some form of path pinning" :)

> My mental operational model of `opam -kgit add pin REPO` has always been (apparently wrong…):
> 
> 1. opam makes its own private `git clone REPO`  
> 2. opam runs `git pull` on this clone on opam `update`
> 
> regardless of whether R is a path or an url. If we agree on this model then yes the branch should be set to the branch seen at pin time since this is the way `git clone` works.
> 
> Regarding converting existing non-mixed mode pins (if that still exists ?) I would say they should be converted to #HEAD so that they retain the previous semantics for existing installations.

Indeed, not how it worked, but that sounds fair enough. Shouldn't be too disruptive to current user if we print clearly "OPAM will track the xxx branch of ..." in the pinning message.

> I still don't get this idea of forgetting to remember to commit. If you forget to commit the pin simply does not update and you see it immediately, so its cost is negligible and I don't think there is a real problem to solve here.  
> 
> For me the problem to solve is *to have* (vs *to forget*) to commit  when you are working on a fix. In these situation, the fact that you have to commit, implies the sequence stage·commit·update·upgrade·(amend·update·upgrade)+ until satisfaction which involves a lot of painful VCS operations and is very costly.
> 
> Here again if you forget the `-w` the pin will not update and you will quickly realize you forgot the `-w`. If you are a heavy user of working dir updates it will become a second nature to issue that `-w` when you update your pin (as it became a second nature to me to do a -kgit on my pin adds to avoid path pinning).

hm, indeed your idea fits better into the "actively working on project y" / "working somewhere else". Maybe the new interface wouldn't cause problems if we use a message like:

    No new commits on branch <branch> of <pkgname>; use
    'opam update -w <pkgname>' if you want OPAM to temporarily use its
    working directory.`

this should probably only be printed on an explicit `opam update <pkgname>` though. Or more importantly on an explicit install/reinstall/upgrade (which triggers update automatically).

> > $ opam pin add -k git foo ./ # or
> > $ opam pin add -k auto foo ./
> > git pinned to currently checked out branch
> 
> I don't think there's the need to have an option for this, it can simply be mentioned in the docs that if you want this you need to pin on REPO#HEAD. I'm pretty sure that in practice what you want most of the time from a VCS pin is to have opam being decoupled from your working directory altogether.

Sorry, that wasn't clear, I did mean "currently checked out branch _at time of pinning_" in both cases. "auto" is just to detect the right VCS.

> > $ opam pin add foo ./
> > [NOTE] ./ is git-controlled, but this will pin to the working directory directly. Use `--kind git` if you want OPAM to track the current git branch instead.
> > Do you want to synchronise only the git-tracked files ? [Y/n]  
> 
> I think you should add `and the .git dir` aswell to be precise. But then I would still claim that had we the `-w` this mode wouldn't be needed. What I don't like with the above is that the system encourages users to use unsafe pin modes and create brittle opam install for themselves. I would rather see the above invocation as simply path-pinning with the NOTE mentioning `-kgit`.

Alright. My point was that "mixed" mode still seems more useful than raw "path" mode in general, so discarding the better one felt weird. But that's notwithstanding the complexity overhead that makes it harder to understand what's going on -- and this may be a good enough reason to tip the balance.

> > Daniel: see what happens when you're not using OPAM's dev branch ? ;)
> Aaah but it's because I trust you… I could have taken the beta though, but OTOH it's the kind of problems that you only see on longer term usage.   

True enough. Well none of these changes seem too disruptive to not add in 1.3.

Cheers,
Louis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20150520/dcf34b83/attachment.sig>


More information about the opam-devel mailing list