You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a small RFC to discuss a possible extension of the make.jl
In a nutshell, the make.jl script could take arguments to allow the user have a bit more control over what it does. I am thinking basically how mkdocs works. So, you would call it like julia make.jl <command>, where the command could be build, clean, deploy, serve etc.
You could also have more arguments, to give even more power to the user, without them having to make changes to the script (e.g. specify the target format, --debug etc). Also, having a serve command would be a first step in addressing #11.
In the make.jl it would look something like this
using Documenter, PkgName
Documenter.run(ARGS; config...)
The implementation actually wouldn't necessarily conflict with the way the scripts work currently, since we can keep makedocs and deploydocs function (and would probably call them in run), even though perhaps in the long term they should be deprecated. Also, build could be the default command, so julia make.jl would work as it does currently.
One more benefit would be that some things would become a bit more explicit. For example, deploydocs currently semi-magically decides if it should do something or not. The explicitness could maybe help with testing as well.
The text was updated successfully, but these errors were encountered:
This is a small RFC to discuss a possible extension of the
make.jl
In a nutshell, the
make.jl
script could take arguments to allow the user have a bit more control over what it does. I am thinking basically howmkdocs
works. So, you would call it likejulia make.jl <command>
, where the command could bebuild
,clean
,deploy
,serve
etc.You could also have more arguments, to give even more power to the user, without them having to make changes to the script (e.g. specify the target format,
--debug
etc). Also, having aserve
command would be a first step in addressing #11.In the
make.jl
it would look something like thisThe implementation actually wouldn't necessarily conflict with the way the scripts work currently, since we can keep
makedocs
anddeploydocs
function (and would probably call them inrun
), even though perhaps in the long term they should be deprecated. Also,build
could be the default command, sojulia make.jl
would work as it does currently.One more benefit would be that some things would become a bit more explicit. For example,
deploydocs
currently semi-magically decides if it should do something or not. The explicitness could maybe help with testing as well.The text was updated successfully, but these errors were encountered: