Code block only for PackageCompiler and not for Revise

Generally you should not add Revise as a dependency of any package. The only exceptions are packages like Genie.jl that explicitly use Revise to provide dynamic updates of code as part of their own functionality. Otherwise, Revise and other “developer” tools should only ever be in your global environment.

Here’s my environment:

(@v1.9) pkg> st
Status `~/.julia/environments/v1.9/Project.toml`
  [1520ce14] AbstractTrees v0.4.4
  [6e4b80f9] BenchmarkTools v1.3.2
  [13f3f980] CairoMakie v0.10.5
  [f68482b8] Cthulhu v2.8.15
  [31a5f54b] Debugger v0.7.8
  [35a29f4d] DocumenterTools v0.1.16
  [5789e2e9] FileIO v1.16.1
  [e9467ef8] GLMakie v0.8.5
  [5903a43b] Infiltrator v1.6.3
  [c3a54625] JET v0.7.15 `~/.julia/dev/JET`
  [89398ba2] LocalRegistry v0.5.3
  [ee78f7c6] Makie v0.19.5
  [85b6ec6f] MethodAnalysis v0.4.13
  [a408fb95] PkgCacheInspector v1.0.0
  [14b8a8f1] PkgTemplates v0.7.36
  [21216c6a] Preferences v1.4.0
  [c46f51b8] ProfileView v1.7.1
  [92933f4c] ProgressMeter v1.7.2
  [295af30f] Revise v3.5.2
  [aa65fe97] SnoopCompile v2.10.7
  [e2b509da] SnoopCompileCore v2.10.0
⌅ [1e6cf692] TestEnv v1.9.3
  [e6125b7d] WhyNotEqual v0.2.0
Info Packages marked with ⌅ have new versions available but compatibility constraints restrict them from upgrading. To see why use `status --outdated`

As you can see, almost everything in here is a developer tool or plotting; AbstractTrees and ProgressMeter are the only two borderline cases. All of my “work” (research/coding/whatever) projects have their own custom environments that omit the developer-tool packages on this list.

This way, I have full access to lots of developer tools, but projects have the minimal stack of dependencies needed for their functionality.

3 Likes