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!
I think thatās slightly ambiguous because it could refer to a āstarting packageā with some default functions for e.g. numerical computing or whatever
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.
.