Many of you have probably noticed this already, but
does not really seem to be a problem in practice. The reason? The best time to set this preference is when you’re in the package’s environment (because you’re developing it), and in that case LocalPreferences.toml will be just that: local to that environment. This gives you the best of both worlds:
- when you’re developing the project (
julia --projectorPkg.activatethe package’s environment, or select it in VSCode), you’re not running the extra precompile workloads - when you’re using the package externally, you do run the precompile workload. This is likely what you want: once you stop developing the project, it’s more likely to be worth investing in extensive precompilation. Of course you can also turn it off in external environments, too, and in cases where you frequently “co-develop” certain package combinations it might be wise to set up a project environment that disables precompilation for all of them. But again, it will take effect only when you’re in that environment.
This is a great example of where the locality of the Preferences system and Julia’s environments really pays handsomely. I’ve found this split to be a huge win for my enjoyment of package development.
Another tip: consider putting LocalPreferences.toml in your global .gitignore. That will prevent you from accidentally checking it in.