Make everything mutable for more convenient in-place updates?

[christopher-dG]

Suppose you have some template saved and you want to create a package from it, but the requirements for this package are just a little bit different than usual, for example you're writing some OS-dependent code and your template has TravisCI(; osx=false, windows=false) because you like to save energy. Currently there's no user-friendly way to update anything in a template, you'd have to create an entirely new one or worry about the Template's implementation details to find + replace the plugin.

One simple solution: Make templates and plugins mutable. The main reason to not do this (AFAIK) is performance, but PkgTemplates isn't really a performance-sensitive package. This change, combined with an easier way to access a template's plugins (probably go back to storing plugins as Dict(Type => Instance()), would make little tweaks super easy. I think it would probably handle #38.

I'm interested in hearing what others think of this.

[rapus95]

I guess that'd help you aswell: https://github.com/jw3126/Setfield.jl
Hopefully JuliaLang/julia#21912 lands in a not too far away future.

[christopher-dG]

I'm not really interested in Setfield for this because I'm thinking from the user's perspective. I don't want to tell people to use a macro to update a property.

[ericphanson]

I think making the Template struct mutable to support changes just kind of makes it so there's two different APIs you'd need to know (the API of the constructor to make templates in the first place, and the more-internal one of the layout struct so you know how to modify it).

What about a constructor Template(t::Template; kwargs...) (or similar) that takes an existing template to use to set the defaults, and then lets you use the usual constructor API to specify changes? (in fact, then the current defaults could just be a const DEFAULT_TEMPLATE = ... and the current constructor could be Template(; kwargs...) = Template(DEFAULT_TEMPLATE; kwargs...) which is maybe kind of elegant?) edit: actually I think that has a bootstrapping issue, nevermind.

edit: also, with the mutable approach, that starts to make the struct layout part of the public API, which might make future development more constrained. It's also hard to put a lid on what bits are expected to be stable and what aren't.

[christopher-dG]

Yeah the Template(::Template; kwargs...) approach is #38. I think it's probably a better idea. Although the internal layout is quite simple and since PkgTemplates is mostly a REPL package, it's easily explorable.

[ericphanson]

Ah, I missed that issue. Well, I like that way :)

[christopher-dG]

yeah ok let's stick with the original plan.