Expose (document) `Pkg.generate` API for programmatic usage

I don’t know if this is on the roadmap but I’d like to encourage documenting and exposing the Pkg.generate API for programmatic usage. Recently I’ve been working on adding a plugins interface for Genie, and part of it I provide a scaffolding method. A plugin is a Julia package with some Genie interfaces - so scaffolding involves creating this Julia package and then setting up some files and a certain folder structure within the package.

However, without a clear API it’s hard to make progress and I don’t want to hack things at file level as that’s brittle and undocumented and can break with changes in Pkg. For instance:

  1. I run Pkg.generate("$user_provided_plugin_name") - how do I programatically retrieve the name of the module and the location of the generated file(s) (what if the user inputs spaces, dashes, casing, etc.)?

  2. I would like to pre-populate the generated module file with the interfaces to help the devs. A newly generated module within a package now has a greet() method and a closing end # module line. I could search for either of these and write my code around them - but these could change at any time, breaking my code.

What’s the best way to solve these problems?

I’ve been looking at PackageSpec but it doesn’t appear to work with Pkg.generate? Also, PackageSpec would have to support a user inputted template instead of the default greet().

1 Like

This is tangential to the Pkg.generate API, but for your use, maybe a custom template or plugin for PkgTemplates.jl might work?

Ah, that’s pretty cool, thank you. I wasn’t aware of PkgTemplates, seems that it could be quite useful!

1 Like

I have thought about deprecating Pkg.generate and just point to PkgTemplates instead. It does almost nothing and is mostly for the Pkg tests itself to use.

4 Likes