easier to use continues integration because for packages this all exists
Current idea for how to use the future package:
mkdir KiteViewer
cd KiteViewer
julia --project
]activate .
add KiteViewer
<backslash>
run()
The function run would then copy some files to the local folder, for example
the default configuration file to data/settings.yaml and a script to launch
the app with the name kiteviewer.sh and a script to create a system image
with the name create_sys_image.sh to the current folder, and finally launch
the GUI application.
Does that make sense?
How would you provide a default config file?
How would you provide a script or a function to create a system image?
According to my experience it is not possible to create a system image
with a Julia script only, because you need to restart Julia to successfully
precompile all required packages, so if you want to automate that you need
a bash script or something similar.
I don’t think there is a completely standardized way to do things right now, so take this as my personal opinion rather than a definitive answer.
I think that if a standardized way of installing applications emerges, it will likely come from this issue:
I think so, but it leaves some aspects unclear to me: would the procedure you describe be the installation procedure, or are users expected to run all these commands each time they want to launch the app? Even if all they have to do for subsequent runs is something along the lines of:
cd /path/to/kiteviewer; julia --project -e 'using KiteViewer; run()'
would you expect them to run this on their own or provide some sort of script to automate this for them? I think most packages that intend to be used as applications ship a script for that purpose, which can be located for example in ~/.julia/bin (that users are expected to add to their path). Making this script portable across OS could be a challenge IMO.
I also don’t completely understand why you need to build a local project, to which you add KiteViewer as a dependency. Unless you want to avoid adding KiteViewer to the default environment?
It could be in the package sources. This would be kind of convenient, because any julia source code knows about its own location via @__DIR__, from which you can reconstruct the location of the default config file.
It is always possible to run a new instance of julia from within a julia script (Base.julia_cmd can help determine the path to the julia executable from a running julia script). So maybe you could have a julia script which runs multiple julia processes to automate the creation of the system image.
In my experience, an other issue is how to run julia with a system image. Unless you expect your users to add the -J command line options themselves, you need some script to automate this. Again, it could be a julia script that detects whether a suitable system image can be found, and if so runs a new julia process to use it.
If you’re going to activate the current directory you don’t gain anything from using --project. I would just combine those two lines into julia --project=.. (There’s a difference between julia --project and julia --project=. when there isn’t (yet) a Project.toml in the current directory.)
Assuming you don’t need to support pre-1.6 Julia versions I would try to use the Preferences and Scratch packages wherever it makes sense in favor of placing data in a local directory.