Invenia is pleased to announce PkgTemplates.jl, a customizable and extensible package for generating Julia packages. As of this post it is awaiting METADATA registration.
Current available plugins:
It also supports an interactive package setup mode with many options that you can see in action in the README.
See the full documentation here.
There is also ANN: PackageGenerator.jl, how does it compare?
… this looks like it largely duplicates what I have done, except that it’s more flexible. I took the approach of prescribing what “should” be in packages for the sake of beginners. However, I would have been open to collaboration if people wanted more flexible options…
@iamed2 if you haven’t already it might be worth looking through PackageGenerator to see if there’s additional functionality not in PkgTemplates. After that’s done, it probably makes sense for me to edit the README of PackageGenerator to send users to PkgTemplates and then stop maintaining it 
Maybe another case of: How does one find a julia package for a specific use?
Actually I don’t see anything in here about API calls at all. @iamed2 it might be worth me eliminating the non-API functionality of PackageGenerator. Then PkgTemplates could REQUIRE (or just subsume) it if it’s functionality you’d be interested in.
Package author here, questions/comments can be directed to me 
. I’m open to suggestions and criticism as this is my first real Julia project.
To address what’s been asked:
@mauro3 One big difference between PkgTemplates and packages like PkgDev/PkgGenerator is customizability and extensibility. My main goal here was to make it dead simple for new plugins to be added (Circle CI is the most likely next addition as of yesterday). I also wanted to give full control to users with custom CI config files etc., and to make templates reusable.
You’re also spot on with your second comment, I had no idea of PkgGenerator’s existence.
@bramtayl Can you elaborate a bit on the API functionality that PkgGenerator offers? From what I can see it looks like it automatically enables the created repo on CI services, which is indeed a nice feature.
Yup. Also links them up to each other so that travis can push Documenter builds to github pages.
I can also mention that we at Invenia have our own plugins for our private infrastructure which makes setting up private or public repos just the change of a template variable (stored in our .juliarc.jl). Much easier for novices than a different of instructions for each!
PkgTemplates already takes care of the second bit, but yes manually adding the repos to Travis/AppVeyor/etc is annoying.
Out of curiousity, how? PackageGenerator runs ssh-keygen then adds repository keys to both travis and github.
Er, sorry I misunderstood. Only the command in .travis.yml is added to build documentation, the keys are still done manually.
I wrote something similar to this a while ago called julz
An example of a codebase written in it is: Tokamak.jl
Does PkgTemplates interact with the package further after it creates it?
Hmm, seems like quite a few people wrote their own version of the same thing (albeit with some cool differences). I suggest we either build a package to automate building packages that help building packages, or try and see how these awesome attempts can be combined into one effort.
The main motive behind this post was my awesome meta joke about the package-building package-building package. Sorry, I’m a dad.
@djsegal that’s an interesting take on it, and indeed very Rails-esque. I’m not sure that I’m completely on board with the approach though, there are a lot of really small Julia packages that wouldn’t make good use of it (I’m making an assumption that Rails applications are significantly larger than Julia packages in the general case). PkgTemplates takes an approach more similar to Rust’s Cargo, providing just necessities by default. Such a structured package layout could be easily integrated into PkgTemplates as a plugin though.
To answer your question: No, nothing is provided for generating code after package creation.
@yakir12 I’m cool with the first idea, I’ll get started immediately with PkgTemplateGeneratorGeneratorTemplates.
I do agree that we should try to find some common ground and combine things, but I’m biased in thinking that they should all be turned into PkgTemplates plugins 
.
I’d be fine if PackageGenerator turned into a PkgTemplate plugin, just don’t have time to implement it.