Code block only for PackageCompiler and not for Revise

General Usage
, ,
1

I’ m searching for ways to workaround can't use revise · Issue #166 · comonicon/Comonicon.jl · GitHub . When developing using Revise, Comonicon and @ccallable functions seem to cause Revise errors that needs restarting REPL. Is it possible to make some code block like the Comonicon macros and @ccallable wrapped block only valid when using PackageCompiler, or on the contrary detect if in REPL or Revise enviornment and don’ t try to Revise them?

Currently I comment them out when developing and comment back when building with PackageCompiler.

2

You probably want to do what PrecompileTools.jl is doing here:

The following will be true when using PackageCompiler.jl (and during precompilation). It will be false for Revise.jl.

ccall(:jl_generating_output, Cint, ()) == 1

@tim.holy do you agree?

3

And I noticed when Revise is added to the Project. The compiled binary would give an error of InitError(mod=:Revise)… when given to another user that doesn’ t have access to my .julia/juliaup/julia-1.9.0.... Should Revise be added just globally?

4

Does Revise.dont_watch_pkgs help?

1 Like
5

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
6

Wow. Thanks for sharing. That’s usually more than I’m willing to put in my global environment. I usually modify my environment stack when I want to use many of those tools.

1 Like
7

Thanks. Maybe separating CLI and C call bindings to a separate package and use dont_watch_pkgs would work. I would try.

1 Like