opam-custom-install issueshttps://gitlab.ocamlpro.com/louis/opam-custom-install/-/issues2022-11-14T17:07:53Zhttps://gitlab.ocamlpro.com/louis/opam-custom-install/-/issues/1Draft: make custom-install more clever and closer to the expected workflows2022-11-14T17:07:53ZLouis GesbertDraft: make custom-install more clever and closer to the expected workflowsThe 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 `compiler` and `conflict-class` fields which leads to all kind of problems
The idea is to move one step (but not more) in the direction of normal pinning/installation:
1. get the existing package definition (either local or from the repo)
1. 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.
1. run the `install` normally, but:
- 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
1. mark the package as pinned with its patched opam file ([to what target ? file://$PWD ? None ?])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 `compiler` and `conflict-class` fields which leads to all kind of problems
The idea is to move one step (but not more) in the direction of normal pinning/installation:
1. get the existing package definition (either local or from the repo)
1. 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.
1. run the `install` normally, but:
- 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
1. mark the package as pinned with its patched opam file ([to what target ? file://$PWD ? None ?])