Draft: make custom-install more clever and closer to the expected workflows
The tool at the moment is very low-level and has a lot of quirks, in particular with its interaction with pinning.
- the next opam command will in general detect a change and want to rebuild the package
- the definition of the existing package is ignored, including e.g conflict fields. Using it on a compiler strips the
conflict-classfields which leads to all kind of problems
The idea is to move one step (but not more) in the direction of normal pinning/installation:
- get the existing package definition (either local or from the repo)
- instead of resolving, just check for the dependencies, excluding
post. Possibly, remove missing dependencies (or installed conflicts) from the package spec automatically since, in this setting, the user is in control.
- run the
- ensure to have no recompilations in the dependency cone of the package (e.g. by ignoring pending reinstalls and fixing the packages in place ? Assuming there are no cycles this should be enough)
- as before, skip the build step and run the provided command from PWD for the install
- mark the package as pinned with its patched opam file ([to what target ? file://$PWD ? None ?])
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information