You are correct. You don’t technically need to develop a “Package”, but you should (at a minimum) create a “Project/Environment” for your application. That way, you can ensure your app will execute correctly - especially if you include the Manifest.toml file. Of course, including a Manifest.toml (project) file also means the user gets locked to the exact solution you specify (will not get updates of dependencies).
To help users run your application on their own system, I suggest:
ConventionalApp.jl
And despite the fact that you don’t need to develop a package, I still suggest you do. I made a conscious decision with ConventionalApp.jl to treat application repositories as a package. Though your app-package does not need to be published in Julia’s General registry, I found it easier for the users to operate on their apps if they are treated as “packages”.
That’s because Julia’s Pkg.jl provides functions & objects that simplify how we access & manipulate packages. For example, a user can add http://url/to/MyPackage.jl to make Julia aware of any github-hosted package. Then, you can call using MyPackage to load it while simultaneously creating a MyPackage module object.
In contrast, Julia’s (non-package) project/environment toolset is not as extensive. ConventionalApp.jl only uses it to setup the active “Julia environment”, making sure the right set of packages are available to your application. (And cleans up the LOAD_PATH to its minimal useful state).
Limitations
I created ConventionalApp.jl out of needs similar to yours. It is a very basic package, but the solution is not completely ironed out. Like I mentioned in my [ANN] post: I feel like I am missing a simpler solution staring me in the face, but I have not yet found it.
But even if this truly is the right way to go, the solution will likely need to be adjusted once people start using it. So feel free to open PRs.