The package is not yet registered, but you are invited to test it - nothing bad should happen .
If anybody comes with a better package name, it is not too late yet.
Now a general question (for the package documentation, not yet written): It is commonly recommended not to work in the “main” environment, but use separate projects (i.e. a folder with Project.toml. While I see the use of it, I prefer to start a (possibly throwaway) package right from the beginning instead of a project. This gives me the important advantage of having all functions, which I place into the project’s module, Revise-ed. I do not see any disadvantages of such a procedure as compared to a bare project. Are there any?
Your post got a lot of likes, which probably refer to the suggested name. Still, I personally am not 100% happy with it.
First, as the package intended for interactive use, it would be nice to have the name which is easy and pleasant to type, which means short enough, easy to memorize, and easy to pronounce (as it is more difficult to memorize things which your can’t pronounce). PkgTemplatesGUI - just try to say it aloud
Second, though PkgTemplates is the backend, StartYourPk adds / going to add some functionality of it’s own (while supporting only a subset of PkgTemplates’s features, on the other side). Furthermore, in the future a switch to BestieTemplate.jl could be an option.
Any more ideas?
Current state: The package appears fully usable on unixes (Mac and Ubuntu), and broken on Windows. Registration presumably delayed till the next year.
I just want to note that ‘easier to pronounce’ is highly subjective.
In particular, to me StartMyPkg is infinitely easier to pronounce since I’m used to finding Pkg all over the place - for what it’s worth, I simply pronounce it package.
Whatever the name - thank you for further enriching the julia package ecosystem!
Being short, euphonic, easy to remember and to type, strongly unambiguous and informative - that is set of requirements which is not easy to satisfy all at once.
(Perhaps this deserves another thread, even though it is in the original post?)
I think that this question is no longer needed if a package is not presented as something different from a project, but as a special kind of project - characterized by the src folder with a jl file containing a module, matching the name of the package.
Under this view, the dilemma of “project or package” is like comparing e.g. “project with or without [compat] section”. The package structure gives the advantages that you mention, at the (minimal) cost of adding a structure that might be superfluous if you are not going to benefit from those advantages.
The package will be renamed to PackageMaker (repo is already renamed), all features I planned to implement before the official release are done, now some minimal clean-up (today?), and go for registration
PackageMaker.jl v0.1.1 is now registered, and should become available in a short time.
Compatibility limitations
Currently may be broken if run from Julia in terminal on Ubuntu. Worked however on same machine from Julia in VSCode. Edit: Traced to an upstream bug, implemented a workaround in v0.1.4
Was also broken on Win10 on Julia v1.10 both from terminal and VSCode, but worked fine under Julia v1.11. Edit: fixed
No issues on Mac .
In the plans: try solve the issues listed above. Most of of the features are already implemented, with exception of saving different sets of default settings for re-use.
And - the boring part - the documentation, tests, refactoring…
.
)
unambiguous and informative - that is set of requirements which is not easy to satisfy all at once.
.