RFC: only auto precompile the added package (+ deps) after an add operation
#3848
Conversation
|
The current approach aims at having the only thing that should cause load-time precompilation being changes to dev-ed packages. This moves more precompilation back to load time, when deps of other packages are changed by an add, which IMO would be a UX regression. But perhaps this is popular? Personally I prefer the current arrangement and using the tiered_installed resolve strategy. Less changes, precompilation stays at install time. |
Yeah, of course, if you precompile the world once you don't have to precompile it later.
Well, it is not a straight-up regression, it is a trade-off. It is a big win in the cases where you do To be honest, with load time precompilation I probably don't see much personal value in the |
|
I think we might have opposite opinions on this. Might be worth fielding opinions on slack? |
|
A fancy solution would be to be specific like this PR, but spawn off the rest of the Project work as a background thing afterwards. The UI of that needs figuring out, but it might not be too tricky..
Pidfile locking should protect against races and we already report if the current process is holding the lock in an async task. |
|
Right now, there is no way to turn off full precompilation of env on |
Many times in the global env I add some small package to try it out and then Pkg starts precompiling everything (even things I did not intend to load). This means I often have to interrupt it (which is a bit brittle) and it feels like it is doing something I didn't ask it to do.
With this, it will only compile the deps graph of the added packages. If a user want to load some other package later, the load precompile step will pick that up.