Re: version pinning in OPAM

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

sounds useful!  i prefer your second suggestion (not having the version number 
in the package being pinned).

would it be possible to extend what you say so that i could type:

$ opam pin mirage 0.3dev        # to pin the mirage package to upstream release 
0.3dev
$ opam pin mirage /local/path   # to pin the mirage package to my local path
$ opam unpin mirage             # to "unpin" and go back to tracking the 
upstream

(or the latter could be "$ opam pin mirage latest" or somesuch if you don't 
want the extra verb.)

if that makes sense?

On 10 Jul 2012, at 23:08, Thomas Gazagnaire wrote:

> Hi,
> 
> Currently, the dev packages of mirage are managed with a special (git) 
> backend in OPAM. As a user, its quite convenient to always have the latest 
> HEAD installed of these packages, but as a developer, you must commit every 
> changes you make in order to trigger a recompilation ... This can quickly 
> become painful, so I've started implementing some kind of version pining for 
> OPAM. I have a first prototype almost working, it allows you to do the 
> following:
> 
>  $ opam pin mirage-0.3dev /local/path  # the path will be used instead of the 
> remote git url
>  [ cd /local/path && hack hack hack ]
>  $ opam update  && opam upgrade # recompile all the packages which depends on 
> mirage-0.3dev, using the contents you have registered with "opam pin"
> 
> Is this convenient ? Would it be better to have "opam pin mirage /local/path" 
> instead (ie. no package version) and a more specific update/upgrade command 
> (like "opam pin -reinstall") to just upgrade the pinned packages without 
> having to do a full upgrade ?
> 
> Under the hook, I've done the following:
> 
> * on init,  we now have a special "rsync" OPAM repository, which will contain 
> the pinned packages
> * each time you call opam pin:
>  - ~/.opam/repo/index is updated to say that the pin repo is prioritary for 
> the the pinned package
>  - ~/.opam/repo/pin/url/$package.$version is created, containing the new path
>  -  the contents of the new path is copied in 
> ~/.opam/repo/pin/cache/$package.$version/
> * on update, I've extended the behavior of the rsync backend to compare the 
> cached version with the actual contents, and to mark the package as new if 
> the diff is not empty
> * the upgrade hasn't changed
> 
> --
> Thomas


-- 
Cheers,

R.




This message and any attachment are intended solely for the addressee and may 
contain confidential information. If you have received this message in error, 
please send it back to me, and immediately delete it.   Please do not use, copy 
or disclose the information contained in this message or in any attachment.  
Any views or opinions expressed by the author of this email do not necessarily 
reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.