I am wondering if there is an established procedure for delivering an application within a Julia package.
I am writing a mesh generator, therefore the main outcome of my package should be a script that reads in user input from a file and then uses the routines in my package to output the mesh. Notably, there is no room for “it will be slow the first time you run it”, since there is no sense in running the script twice – once the mesh is there we are done.
To have an analogy, in python application delivery is achieved with “entry points” defined in the setup file of a package. After runnin the setup you can run your script from the terminal. What is the procedure is Julia? I tried to find inspiration in other package, but had hard time finding a package that actually delivers an application and not just an API.
Currently, what I have is a separate module that is using the main module of the package, the one defining the mesh generation routines. In this separate module I have a main() function that basically does all the stuff, and which is called when the module is included. Is this the way to go? Does this ensure that things run fast “from the first time”? I still need to write julia path_to_script to run it, can this be simplified?
For what it’s worth: I believe that you would want to have the heavy lifting code inside a module. That encapsulation makes it possible to achieve type stability. Then the module can be called from your script without a run-time penalty.
The compilation time will presumably be fairly small compared to the expense usual in generating substantial meshes.
In any case, it will likely not generate just a single mesh, but a sequence of meshes? In that case the compilation of the module holding your “library” code will be performed just once.
Type stability has nothing to do with modules. Type stability is a property of a method (function and types of the arguments).
Putting code in a module does not by itself change any first run time-penalty. If you make it a package, you can put a __precompile__() directive on the module which helps a bit. However, first call will still have a compilation cost. That cost might very well be insignificant compared to the time to read the mesh though.
A global in a module is not better than a global in a script. In fact, a script happens to execute in the Main module, so there is actually no difference.
Thank you for the replies regarding performance! I will try to add precompile to the modules.
Actually compiling to a binary would be a nice option, but this functionality is still very experrimental and perhaps not always needed. To make things smoother currently, one can add #!/path/to/julia at the top of the application julia file and then add the folder with file to the $PATH. However, as far as I understand there is no system for streamlining this process, and this has to be left to the user.
I think Julia would really benifit by setting up something like entry_points in python!