The idea here is that by standardizing what the entry-point looks like, future iterations of (Package-,Static-,etc)Compiler will be able to automatically turns scripts with these patterns into compiled applications. However, as a result, if you are currently using this pattern, you will have to adjust it to the standardized variant.
The most common change that is required is:
The standard version takes ARGS, so youâll have to add that to your function signature:
function main(ARGS)
# stuff
end
Base.ARGS continues to remain available, but it is recommended to switch to the passed ARGS instead for future compatibility (if youâre doing argument processing at all - if not you may ignore the argument, but you should still have it in your signature).
The main function is called automatically. If youâre living on master, that means you can simply delete the call to main. The julia driver will call it for you. If you want to support both versions, the recommended incantation is:
!isinteractive() && VERSION < v"1.11.0-DEV.403" && exit(main(ARGS))
I recognize that there may be some inconvenience and breakage in scripts, etc. due to this change, but hopefully itâll be quick to fix and enable a smooth transition to fancier workflows in the near future.
This is neat and useful, but is this not a breaking change that goes against the âspiritâ of semantic versioning? I know this question has come up before â I have tried to read through the core developersâ comments in previous threads in order to learn the âflavorâ of semver that they have adopted for julia, but this particular change still surprises me. Is there a more formal reasoning here than âby our estimate, this is sufficiently painless of a breakage with sufficiently big upsideâ?
To be fair, this reasoning seems good enough to me as the upside is obvious and the breakage is indeed minor (I have experienced way worse breakages in python and its ecosystem, for instance), but some more formal description of the reasoning will be helpful in building my mental model of what semver means for julia.
I think this is going to catch many more people off guard once 1.11 is released, potentially for years to come when they rerun old code (or just think of someone trying to reproduce some paper⌠). Itâs unfortunate that the breakage was not anticipated, but as a PkgEval would have caught this, itâs a shame that weâre now going to have broken PkgEval until this is solved one way or another.
I would absolutely consider this a breaking change, but having Base.main instead of Main.main seems like it would perfectly solve the problem, and be a really nice feature.
Could we throw a very informative error if the main signature doesnât match the new format and add a command line flag for running without the new entry point? Then there would be an easy path for later to get the old behavior back when running old code. Something like --nomain or so.
That was also my first impression but now I think it would be a confusing hack: this main is really about Main, not Base, and itâs not a regular method. So Base.main would be misleading.
Hereâs what Keno wrote in the PR:
This is not workable, because this is designed to support Main.main bindings that are things other than methods of a generic functions. It also breaks the julia -e 'using MyApp' thing, because it requires type piracy and if some other package also has a main function, suddenly youâve broken precompile.
Also, âmaking compilation first classâ is a huge deal and a massive win for the language, and first class means main rather than something âconvolutedâ like Base.main.
Just so everyone is on the same page, @Keno what do you consider on topic here? IMO, Discourse is a much better place to have such (potentially) long, diverging discussions with lots of opinions, so it would be better to discourage people from having this general discussion on the Github PR, and keep the PR comments to specifics about this implementation. Either this Discourse thread or a new thread split away from this would be a better place for the âis this breaking and how do we mitigate thatâ discussion.
Well, kind of depends on where the GitHub thread is going - if the change is getting reverted, then thereâs broader discussion to be had there. I guess for the moment, that means concrete technical suggestions about what to do instead go on GitHub, general griping about my cowbody attitude can remain here and personal attacks can remain in the usual social media channels . I realize that I probably set the wrong precedent for that by replying to the question about breaking changes on GitHub.
I disagree that __init__is like main. Using C as a comparison, it would be __attribute(constructor)_, while main is main. One is present in all executables while the other is a special behavior that isnât super common.
). Itâs unfortunate that the breakage was not anticipated, but as a PkgEval would have caught this, itâs a shame that weâre now going to have broken PkgEval until this is solved one way or another.
. I realize that I probably set the wrong precedent for that by replying to the question about breaking changes on GitHub.