[opam-devel] On the new mixed mode pins

[David Sheets]

On Sat, May 16, 2015 at 2:00 PM, Daniel Bünzli
<daniel.buenzli at erratique.ch> wrote:
> Le samedi, 16 mai 2015 à 13:22, David Sheets a écrit :
>> I don't usually use `opam update -u`
>
> Right me neither, I do both operations in sequence but usually don't have a close look at the proposition. I tend to trust the work of the opam repo maintainers (shouldn't I ?).

As we bring more test systems online and automate their integration,
yes, this will become safer. My primary reason for lazily upgrading is
timeliness. I prefer to let the solver determine the minimal plan to
satisfy my requirements. I definitely trust the opam repo maintainers
more than I should for package lower bounds and this is one aspect of
repository health that we're working on with increased testing.

>> I think that, whatever the outcome of these discussions, the mixed VCS
>> vs. explicit branch VCS modes should be made clearly distinct.
>
> Yes, that was my initial reaction and proposal in this comment:
>
> https://github.com/ocaml/opam/issues/2141#issuecomment-101994075
>
> But by thinking more about this, I had the impression that we could kill a few concepts and get a simpler and better system for the end-user.

Indeed I believe the current meaning could be simplified and
clarified. My recollection is that we realized that defaulting to VCS
pins *alone* required too much VCS manipulation in the simplest cases
of new users or small pin counts. In response to that issue, Louis
expediently and cleverly devised the current mixed mode pinning. I
agree it could use revision and, retrospectively, explicit dirty
requests would have been a cleaner design.

>> Afaik, git conventionally uses 'master' but this is only convention
>> and there is no mechanism to change this. Is that correct?
>
> In fact if we wanted to be consistent with what a `git clone` would do (the least surprising in my opinion), we should maybe rather take the repository's current active branch whenever we `opam pin -k git $PATH`.

Agreed. This is the same VCS reference semantic that the mixed mode
VCS pins currently have. This does make the VCS mode dependent on
local working tree state and divergent from a remote repository but I
believe this state is so small and 'obvious' as to be acceptable.

>> What happens with a branch pin that is dirty-updated? Does it take the
>> working tree or only the working tree if the branch is the same?
>
> I would say let's keep this simple. This should mean: take the on-disk state of git-tracked files currently checked out in the working directory of the pin's git repo. Don't lookup branch information.
>
>> Or the working tree with the file filter of the branch specified? It
>> seems that working tree filtered by *current* branch is simplest which
>> you suggested.
>
> Not sure what you mean by file-filter. If you mean only take the on-disk state of the git-tracked files that are checked out in the working directory *and* are also tracked by the branch then I think the semantics is too tricky.

Yes. I think ignoring any branch pin in the case of working directory
installs is a little strange but does make some kind of sense. After
all, it is called working directory...

> I really want this to be obvious: now look at all the git-tracked files in the repo's working directory and try to use this for installing. (For this reason —working-dir may be a better name than —dirty, also it happens that `-w` is not used whereas `-d` is).

in the repo's working directory *on the currently checked out branch regardless*

>> > I think that this would make a much more usable and and conceptually clean model of VCS pins.
>>
>> This is definitely a cleaner model than what we currently have. Do you
>> have objections against a solution using a pin parameter like `opam
>> pin -k git+dirty repo` which would behave as mixed mode currently does
>> except imply `--dirty` on relevant operations?
>
> Did you mean "would behave as mixed mode currently does *by* implying `—dirty` on relevant operations ?"

Yes, sorry for the confusion.

> No strong objection, but my initial aim was to try to reduce the pin modes to simplify the system both conceptually and from an implementation point of view. To me non automatic —dirty seems to be the only sane way of working with VCS pins if you need to scale. If you need something that always auto-syncs on sources you can still use path pins (as long as you do not build anything in them).

I think it really depends on your development practices and/or use of
indiscriminate upgrade. I'd be happy in a world where I have an escape
hatch (--working-dir) from the VCS pin. "+dirty" simply retains the
current behavior if desired or as default. I don't know if it's worth
implementation for user consistency/quick-and-dirty introduction.

I would like a message printed when pins are synced in a VCS mode that
would sync differently in a dirty mode.

> It seems [1] that Louis tried to avoid having explicit dirty modes as it doubles the number of modes, but I think that by doing so the pin system became semantically much too obscure (cf. the comment I mentioned above).

It's like a higher-order pin mode ('path+dirty' = 'path'?).

> [1] https://github.com/ocaml/opam/issues/2033#issuecomment-76321338

Thanks,

David