comonicon
Support different targets
I think as for Comonicon projects, this is quite simple, we can just have an extra field in Comonicon.toml to control this (which also means a newly available kwargs in install and build), e.g
name = "ion"
target = ["julia/basic", "completion/zsh", "julia/poptart"]
however, if we generate an entry for GUI, we might want to have different installation options/paths for target julia/poptart, e.g on Mac OS, this should in the Applications folder, which makes it more viable to the system instead of .julia/bin. We might want to have some more detailed configurations. I haven't come up with a good design on this yet, let me think about it a bit more.
I am not sure how target can be used in install and build.
If it is in Python, I would import a package that provides the corresponding codegen for target when reading configs.
In Julia, it is not allowed to import a package in a function. It seems to me that this means either packages that provide targets become dependences of Comonicon or users manually import the packages.
We certainly do not want the latter one. Is there a better solution other than making all extended packages as dependence?
target is a parameter for codegen, and codegen itself doesn't necessarily need to depend on the runtime it targets (tho for convenience it sometimes depends on that).
If it is in Python, I would import a package that provides the corresponding codegen for target when reading configs.
Note, this can be a harmful way of writing a package that aims for stable behaviour, there's going to have no way to do version control on the dependency. It can be a bad design in Python and cause a lot version conflicts, unless the developer handles all the version control inside the code at runtime, which is too evil.
We certainly do not want the latter one. Is there a better solution other than making all extended packages as dependence?
IIUC, currently ComoniconGUI does not overloads the interfaces of Comonicon, e.g
https://github.com/Eggiverse/ComoniconGUI.jl/blob/master/src/codegen/poptart.jl#L44
as a result, it conflicts with the interface of Comonicon, the right way is to make overlapping part (which is all the parse code) and overload the function Comonicon.codegen rather than define your own ComoniconGUI.codegen. Then simply depends on Comonicon will provide a stable way to insert codegen passes with version control.
This is also the point of multiple dispatch and generic function: a safer way to write runtime overloaded interfaces.
The first thing I'd do is to try to move whatever is missing in the parse part to Comonicon, given this should be the same for both GUI and CLI as a frontend. Unless you want to support a different semantic in the API, which is going to be much more work than the current implementation in ComoniconGUI.
Currently, configuration (Comonicon.toml) is not loaded if it is not used for a Package.
This needs to be changed if target is in the configuration.
Is it going to call install whether it is in a Package or a new function other than install is going to be used?
I just realize we probably want to wait for 1.6's new stdlib Preferences.jl (https://github.com/JuliaLang/julia/pull/37595) so that the user can choose whether to use GUI or CLI or both as an external switch for the codegen/build function instead of doing a workaround ourselves. This configuration is likely configured only be the user and as developers, we actually won't be able to know what to install unless things are built into standalone applications.
I am studying how Pluto works and try making a web-based GUI target.
During this, I will try exploring how different GUI targets coexist.