pinning/installing issues

[progman1]

I am trying to do a simple thing - tell opam to take a local directory
as the home of a package. I don't want it looking at the version control
or caching any files - when I make a change I want to be able to
just tell opam to replace the current installation with a new one.

this looks like a two step process, first pinniing then installing, thereafter updating.
so pinning has this option --kind that looks like it allows to avoid looking at versioning
systems. <path> looks like the best bet, but the man page only says that's what is defaulted to when the vcs cannot be determined - it says nothing about what it actually does do in its own right. If I understand correctly this man page is the documentation
so I tried it and the result is an rsync of the directory which is undesirable because in the install step I'm going to use --inplace-build which obviates the need for any copying IIUC.
perhaps <none> was the right choice? In trying this the package is listed as having a version.
but didn't I say don't look at the vcs?! I'd rather explicitly give it a dummy version if it's really necessary.
I try anyway and the build fails citing dune not knowning what to do with the unrecognised package name. dune?! I had changed my opam file to use make! where is it getting dune from?

about the install step: if it is not actually possible to tell pin to ignore the vcs how about
--working-dir on the install step? I still see "synchronised from git+file: ....#master" !
additionally , depsite using --inplace-build I also see rsync being invoked again.

lastly, each of the pin and install steps I assume are running the solver and so taking an
inordinate amount of time of my system. Is there any way to short-circuit this for the sake
of development purposes?

I'm using opam 2.0.1

[rjbou]

First of all, opam always retrieve source code in its internal, depending on pin kind and working-dir option:

• path-pinned: rsync all root directory, with some exclusions (vcs, build, opam, etc.)
• vcs-pinned: vcs fetch
• working-dir : first sync with pin kind (usually vcs), then retrieve (rsync) all missing files (uncommitted changes, new/removed files)
  • That's why you see the "synchronised from git+file: ....#master"

So here, for the in-dev project, you can use a path pin or working-dir option, depending on what is the best on your case (incremental rsync or incremental git+rsync).
Note that there is fixes on inplace-build/working-dir 2.1~alpha: #3948, #3982, etc. (full list working directory release note item).

For your last question, the solver is always invoked, but you can use the opam lock plugin (integrated in opam 2.1*) to set a locked version of your required packages, like that the solver would have quite nothing to do (and takes much less time usually).

On dune issue, I'll need more information, I don't see from where this dune invocation comes from.

[progman1]

#3948 mentions a dirty sync which to my mind doesn't square with the documentation
for --inplace-build.
my reading of the doc string for --inplace-build is:
o don't retrieve src from anywhere, it's already there
o don't clean out build artefacts prior to building

so to see git fetching or rsyncing seems completely contrary to that.
is my interpretation wrong?
if so, do I have to hide the .git directory to fool opam into using only the local source as is?

thanks.

[progman1]

perhaps my use case is not catered for.
here it is in painful detail:

• I have a project I push to github for backup and to publish
• my local repo is the definitive source of the latest version
• I work on it and when it's in a suitable state I want to see that
  a) it installs ok through opam
  b) that the new version is picked up by some other project that utilizes it
  and is benefitting from whatever changes I have made
• since everything is compiled in release mode I don't need another recompile
• since the defintive source is right there I don't expect opam to try and get it from
  anywhere else.
• I expect opam to issue it's build instruction which comes back almost immediately
• then opam installs and fulfills its administrative functions
• I test my other project, rinse and repeat

I imagined this to be the common way. If it is not, where am I varying from that common way?

[dra27]

--inplace-build should guarantee that the build instructions are not repeated - the synchronisations are to do with pinning so that opam can detect if it's changed and so update the switch (and rebuild any dependent packages, etc.)

If you want to test that your package is installable in opam, then you also need to build it in opam. There are many things which your proposed workflow is not testing:

• The build instructions in the opam file are ignored, and so not checked
• Sandboxing, Dune vendoring (granted, I know you said you're not using Dune in this case) and other aspects of your environment may render your build artefacts relevantly different

On the other hand, if you combine a caching build system with opam, then you can test all this normally without recompiling - the Dune cache, for example, would allow you to develop locally and then install a real clone of the sources and Dune will automatically use the cached release artefacts.

[progman1]

@rjbou, @dra27
most helpful info. perspective adjusted. thank you!

[progman1]

.

[dra27]

I think that the conclusion of this was that nothing would be changed in opam - please feel free to re-open if not!