{"action":"created","issue":{"url":"https://api.github.com/repos/ocaml/opam/issues/2532","repository_url":"https://api.github.com/repos/ocaml/opam","labels_url":"https://api.github.com/repos/ocaml/opam/issues/2532/labels{/name}","comments_url":"https://api.github.com/repos/ocaml/opam/issues/2532/comments","events_url":"https://api.github.com/repos/ocaml/opam/issues/2532/events","html_url":"https://github.com/ocaml/opam/issues/2532","id":150959500,"number":2532,"title":"Next, Feature request: `opam switch pin`","user":{"login":"Drup","id":801124,"avatar_url":"https://avatars.githubusercontent.com/u/801124?v=3","gravatar_id":"","url":"https://api.github.com/users/Drup","html_url":"https://github.com/Drup","followers_url":"https://api.github.com/users/Drup/followers","following_url":"https://api.github.com/users/Drup/following{/other_user}","gists_url":"https://api.github.com/users/Drup/gists{/gist_id}","starred_url":"https://api.github.com/users/Drup/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Drup/subscriptions","organizations_url":"https://api.github.com/users/Drup/orgs","repos_url":"https://api.github.com/users/Drup/repos","events_url":"https://api.github.com/users/Drup/events{/privacy}","received_events_url":"https://api.github.com/users/Drup/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2016-04-25T19:34:45Z","updated_at":"2016-05-04T09:06:13Z","closed_at":null,"body":"See https://github.com/ocaml/opam/issues/2531 for the previous part.\r\n\r\nIn order to avoid doing \r\n```\r\n% opam switch install 4.03.0+trunk\r\n% opam pin add ocaml source/ocaml\r\n```\r\nwhich compiles the compiler twice, I would like to be able to say\r\n\r\n```\r\n% opam switch pin ocaml.4.03.0+patate source/ocaml\r\n```"},"comment":{"url":"https://api.github.com/repos/ocaml/opam/issues/comments/216801810","html_url":"https://github.com/ocaml/opam/issues/2532#issuecomment-216801810","issue_url":"https://api.github.com/repos/ocaml/opam/issues/2532","id":216801810,"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":"2016-05-04T09:06:13Z","updated_at":"2016-05-04T09:06:13Z","body":"> The basic usage that we want to support for most, and in particular beginners without getting too confusing is to create a switch with some compiler inside.\r\n\r\nThe beginner argument is, as usual, fallacious. People who mention supporting beginners should read more books about usability. You don't want to support beginners, you want to expose a simple conceptual model that both the beginner and the working user are able to quickly grasp, remember and work with pleasantly.\r\n\r\nSuch a simple conceptual model is: a switch is just a named empty space where you can install packages in isolation from other switches. When you create a switch you can mention a switch init (export) file that will immediately install the packages mentioned therein.\r\n\r\nI think that the conceptual model you expose at the moment is mess and won't scale gracefully to encompass further developments of OPAM (e.g. see below). \r\n\r\n> While I can see some advantages, I am not fully convinced: first, it will annoy me for putting in place repository signing :p.\r\n> But also, and more generally, it brings back (some) complexity that part of my goal was to avoid by removing .comp files, and re-adds multiple formats to the repository. For example, this is an issue for proper linting and checking of PRs.\r\n\r\nThese are technical issues. Favouring technical issues over usability and exposition of a simple conceptual model is not a good idea. Looking beyond, the model I propose adapts very well with the possibility of adding local, per-project, switches. In this case when you do an `opam create NAME --local` in a directory it would read from a local `.opam_switch` switch init file the universe to initialize in order to get a working environment for the project.\r\n\r\n> On mixins\r\n> Interesting ideas, and that seems like it could be useful. However, it seems a bit overkill to me, and adds a whole lot of mechanisms that could be difficult to track (think about conflict messages).\r\n\r\nMaybe overkill and too complex, if you have better proposals I'm all for it. The problem that needs to be addressed is: an *easy* and *efficient* way to move and update package constraints between otherwise isolated switches. \r\n\r\nIn my opinion neither `export` in its current state, nor virtual packages, nor introducing a notion of shared pin between switches (which seems very ad-hoc and complexifies the model) fit that bill. The advantage of mixins is that they are somehow just opam switch init files --- which again fits with the conceptual model above --- that are easy to apply and update to arbitrary switches. \r\n\r\nMaybe we can drop the idea that switch remember which mixins where applied to, i.e. updates to mixins do not affect switches, that would already be a significant improvement over the status quo. In fact mixins could simply be a command that manipulates switch init files, you have those that are provided by the repo which are immutable and you can create and update your own local init files, e.g. by adding constraints manually, by snapshooting the constraints of a set of packages in a given switch etc.\r\n\r\nI know you'll tell me all this can already be done using `export` files, sure it can be done, but it's all very cumbersome. We need a good UI and conceptual model for this. \r\n\r\n\r\n"}}