When working on a project (not a package, not intention of re-use), I started usin

General Usage
1

When working on a project (not a package, not intention of re-use), I started using Revise and includet. Once my project got larger, I figured it was best to put it into a module. Everything is in functions already. I don’t have any scripts that run.

However this comes with costs. I have to explicitly export things if I want to use them. This makes debugging at the command line harder.

If I stick with includet, what are the downsides? It looks like includet includes method deletion now, so debugging is easier. Am I wrong to think that it’s “best practice” to put things into a module even if I don’t intend on re-using them?

Any thoughts are appreciated.

Note that the poster on Slack cannot see your response here on Discourse. Consider answering the question there or pinging the poster here on Discourse so they see the reponse.
(Original message :slack:)

1 Like
2

Update from slack:

  1. If you want to enable precompilation of your functions, use a module. However as this is a project that is not designed for re-import into another body of work, this is not an added benefit of modules in this context.
  2. You can use
for n in names(@__MODULE__; all=true)
    if Base.isidentifier(n) && n ∉ (Symbol(@__MODULE__), :eval, :include)
        @eval export $n
    end
end

at the end of your module to automatically export all Symbols.

However this has no added benefit that just working with includet doesn’t provide, at least for my use case.

So I think it is best to keep includet for now. My final concern is that I don’t know if includet is as feature rich as using Revise with a module.

If anyone has examples of edge cases in which using Revise with a module works but includet has some problems, I would appreciate hearing them.

4 Likes