{"action":"created","issue":{"url":"https://api.github.com/repos/ocaml/opam/issues/2156","labels_url":"https://api.github.com/repos/ocaml/opam/issues/2156/labels{/name}","comments_url":"https://api.github.com/repos/ocaml/opam/issues/2156/comments","events_url":"https://api.github.com/repos/ocaml/opam/issues/2156/events","html_url":"https://github.com/ocaml/opam/issues/2156","id":78468462,"number":2156,"title":"Pin down the pin system semantics","user":{"login":"dbuenzli","id":485596,"avatar_url":"https://avatars.githubusercontent.com/u/485596?v=3","gravatar_id":"","url":"https://api.github.com/users/dbuenzli","html_url":"https://github.com/dbuenzli","followers_url":"https://api.github.com/users/dbuenzli/followers","following_url":"https://api.github.com/users/dbuenzli/following{/other_user}","gists_url":"https://api.github.com/users/dbuenzli/gists{/gist_id}","starred_url":"https://api.github.com/users/dbuenzli/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dbuenzli/subscriptions","organizations_url":"https://api.github.com/users/dbuenzli/orgs","repos_url":"https://api.github.com/users/dbuenzli/repos","events_url":"https://api.github.com/users/dbuenzli/events{/privacy}","received_events_url":"https://api.github.com/users/dbuenzli/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-05-20T10:29:08Z","updated_at":"2015-10-15T13:27:50Z","closed_at":null,"body":"See discussions in http://lists.ocaml.org/pipermail/opam-devel/2015-May/001068.html and https://github.com/ocaml/opam/issues/2141\r\n\r\nThe semantics is currently confusing and the default mode of operation dangerous in the sense that it's too dependent on the current state of your file system, which makes it easy to pick up unwanted state when you deal with many pins over a long period of time, as you need to remember the exact checkout state of your pins whenever you do an `opam upgrade -u`. Besides currently vcs-pins are completely inconsistent in the sense that the behaviour is very different on a `pin add -kgit` depending on whether `REPO` is an URL or a local repo.\r\n\r\nThe pin system should be changed so that the following mental model is preserved whether `REPO` is an URL or a local repository which is not the case at the moment,  `opam -kgit add pin REPO`:\r\n\r\n1. opam makes its own private `git clone REPO`\r\n2. opam runs `git pull` on this clone on opam `update`\r\n\r\nW.r.t. to the current behaviour it means that adding a new `git`-pin no longer tracks `HEAD`, but the currently checkout-out branch in the repo (the value of `git symbolic-ref HEAD`). Recovering the old behaviour can be achieved by specifying `REPO#HEAD` on the command line. The `opam pin list` dashboard should also be made more explicit so that's it's easier to see what is going on by printing `$PKG git $BRANCH $REPO` rather than the hard to parse `PKG git $REPO#$BRANCH`.\r\n\r\nIn order to support workflows where you may want to test for a change in the working directory of the pin without having to commit on the tracked branch. The `-w/--working-dir` option is added to `opam upgrade/install/reinstall`. In this case the semantics is as follows, rather than looking at the branch information of the pin, opam picks up the on-disk state of git-tracked files currently checked out in the working directory of the pin's git repo and uses this to install the package. This state is kept on further opam updates until the branch of the pin changes again or a new `-w` upgrade is requested.\r\n\r\nI would personnally say the mixed-mode pins as they exist now should not be needed with such a system and can be killed. Simple path pinning should simply rsync. More precisely the use-case for mixed-mode was:\r\n\r\n1. Being able to test changes in a pin without having to commit and without having the build pick up build artefacts (which can occur with simple path-pinning). This use case is well supported with `-w`. \r\n2. Use of `(re)install` that don't allow you to see if changes were picked up. This is rather a command misuse. By using `opam upgrade` you will always know if changes are being picked up or not. \r\n\r\n\r\n\r\n\r\n\r\n\r\n \r\n\r\n\r\n\r\n\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/ocaml/opam/issues/comments/148385490","html_url":"https://github.com/ocaml/opam/issues/2156#issuecomment-148385490","issue_url":"https://api.github.com/repos/ocaml/opam/issues/2156","id":148385490,"user":{"login":"dbuenzli","id":485596,"avatar_url":"https://avatars.githubusercontent.com/u/485596?v=3","gravatar_id":"","url":"https://api.github.com/users/dbuenzli","html_url":"https://github.com/dbuenzli","followers_url":"https://api.github.com/users/dbuenzli/followers","following_url":"https://api.github.com/users/dbuenzli/following{/other_user}","gists_url":"https://api.github.com/users/dbuenzli/gists{/gist_id}","starred_url":"https://api.github.com/users/dbuenzli/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dbuenzli/subscriptions","organizations_url":"https://api.github.com/users/dbuenzli/orgs","repos_url":"https://api.github.com/users/dbuenzli/repos","events_url":"https://api.github.com/users/dbuenzli/events{/privacy}","received_events_url":"https://api.github.com/users/dbuenzli/received_events","type":"User","site_admin":false},"created_at":"2015-10-15T13:27:50Z","updated_at":"2015-10-15T13:27:50Z","body":"There is also another issue I often run into. When you develop for the next release you do: \r\n\r\n```\r\nopam pin add -kgit PKG PKG-repo#master\r\n```\r\n\r\nYou then make you release, it gets into the opam repository you do an `opam update` and then you do a \r\n\r\n```\r\nopam pin remove PKG\r\n```\r\n\r\nIn this case it will reinstall the version of `PKG` that was there when you pinned `PKG`, is there any good reason why it doesn't try to install the latest version provided the installed constraints allow it ?\r\n\r\nThe current behaviour for me often either leads to downgrades which I need to reupgrade and/or breakage, followed by a manuall reinstall of many packages. This is annoying if your package is a highly used dependency.\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n \r\n\r\n"}}