Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build directories kept again for pinned packages #4255

Closed
Blaisorblade opened this issue Jun 30, 2020 · 4 comments · Fixed by #4436
Closed

Build directories kept again for pinned packages #4255

Blaisorblade opened this issue Jun 30, 2020 · 4 comments · Fixed by #4436
Milestone

Comments

@Blaisorblade
Copy link
Contributor

Blaisorblade commented Jun 30, 2020

#266 came up again. I have installed packages without the --keep-build-dir option (or corresponding environment option), yet build folders were kept and occupied 3G. Anything that could explain it?
I've learned to use opam clean as a workaround, but I thought I'd file this issue for future users anyway.

Also, FWIW, I don't know how to reproduce it. I'll try

$ opam config report
# opam config report
# opam-version      2.0.7
# self-upgrade      no
# system            arch=x86_64 os=linux os-distribution=debian os-version=10
# solver            builtin-mccs+glpk
# install-criteria  -removed,-count[version-lag,request],-count[version-lag,changed],-changed
# upgrade-criteria  -removed,-count[version-lag,solution],-new
# jobs              1
# repositories      2 (http), 2 (version-controlled) (default repo at 24cd8ca3)
# pinned            1 (git), 2 (version)
# current-switch    ocaml-variants.4.07.1+flambda
$ du -h --ma=1 ~/.opam/ocaml-variants.4.07.1+flambda/.opam-switch/
8.0K	/home/artifact/.opam/ocaml-variants.4.07.1+flambda/.opam-switch/backup
8.0K	/home/artifact/.opam/ocaml-variants.4.07.1+flambda/.opam-switch/config
188K	/home/artifact/.opam/ocaml-variants.4.07.1+flambda/.opam-switch/packages
12K	/home/artifact/.opam/ocaml-variants.4.07.1+flambda/.opam-switch/overlay
2.9G	/home/artifact/.opam/ocaml-variants.4.07.1+flambda/.opam-switch/build
87M	/home/artifact/.opam/ocaml-variants.4.07.1+flambda/.opam-switch/sources
676K	/home/artifact/.opam/ocaml-variants.4.07.1+flambda/.opam-switch/install
3.0G	/home/artifact/.opam/ocaml-variants.4.07.1+flambda/.opam-switch/
$ opam pin
coq.8.11.2+flambda-byte    version  8.11.2+flambda-byte
coq-autosubst.dev.coq86    version  dev.coq86
dot-iris-builddep.~dev     git      git+file:///home/artifact/dot-iris#final-artifact
$ opam list
# Packages matching: installed
# Name                # Installed               # Synopsis
base-bigarray         base
base-threads          base
base-unix             base
conf-findutils        1                         Virtual package relying on findutils
conf-m4               1                         Virtual package relying on m4
coq                   8.11.2+flambda-byte       pinned to version 8.11.2+flambda-byte
coq-autosubst         dev.coq86                 pinned to version dev.coq86
coq-iris              dev.2020-06-29.0.462b056f This is the Coq development of the Iris Project
coq-iris-string-ident dev                       Add support for Gallina names in intro patterns to the Iris Proof Mode
coq-stdpp             dev.2020-06-17.1.370c0cf4 std++ is an extended "Standard Library" for Coq
dot-iris-builddep     ~dev                      pinned to version ~dev at git+file:///home/artifact/dot-iris#final-artifact
num                   1.3                       The legacy Num library for arbitrary-precision integer and rational arithmetic
ocaml                 4.07.1                    The OCaml compiler (virtual package)
ocaml-config          1                         OCaml Switch Configuration
ocaml-variants        4.07.1+flambda            Official release 4.07.1, with flambda activated
ocamlfind             1.8.1                     A library manager for OCaml
@rjbou
Copy link
Collaborator

rjbou commented Jun 30, 2020

Since few years (pr #2593), build directories are deleted bot not for pinned packages. I guess that it is because when a package is pinned, it is generally an in development package, and it is intended to be rebuild frequently, so to save time, build directory is kept. @AltGr is there another reason?

Thanks for the report!

@Blaisorblade Blaisorblade changed the title Build directories kept again Build directories kept again for pinned packages Jun 30, 2020
@Blaisorblade
Copy link
Contributor Author

Thanks for the response!

Since few years (pr #2593), build directories are deleted bot not for pinned packages. I guess that it is because when a package is pinned, it is generally an in development package

  • Uh, weird. I always pin Coq and dependencies for the opposite reason — they're never meant to be updated automatically. If my project is written for Coq 8.8 and Iris 1.3, I don't care for 8.43 was released. The Docker images for Coq do the same thing (but they do call opam clean). Also, the PR author could have mentioned this — but maybe they did and I'm just too blind to see it.

  • It's true I also have packages pinned by branch, which suggests they'll be rebuilt, but those are very small.

  • If this behavior is kept, opam pin could at least print a message, and this could be documented more.
    FWIW, opam pin --help says nothing special on --keep-build-dir, just the same as opam install --help.

@AltGr
Copy link
Member

AltGr commented Jul 1, 2020

Uh, weird. I always pin Coq and dependencies for the opposite reason

Maybe we should have a different behaviour on version pinning vs source pinning, which are pretty different in many aspects... The change should be pretty straight-forward here: https://github.com/ocaml/opam/blob/master/src/client/opamSolution.ml#L690

Have you checked if opam clean -s has any effect ?

In the case of source-pinned packages, we were expecting at some point to use the data in the left-over build dir to e.g. check the git refs w.r.t. the current source; but apparently it's not used at the moment.

Note that another reason to keep the build dir could be debug options and when the build failed, so that you can troubleshoot.

@Blaisorblade
Copy link
Contributor Author

Maybe we should have a different behaviour on version pinning vs source pinning, which are pretty different in many aspects...

Sounds much better! :-)
Ideally make opam pin tell me — also, what's the negation of --keep-build-dir?

Have you checked if opam clean -s has any effect ?

It does work.

Note that another reason to keep the build dir could be debug options and when the build failed, so that you can troubleshoot.

Absolutely, and there's also --reuse-build-dir which I guess is great for source pinning.
But as we seem to agree, please not by default for version-packages :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants