Enable scaffolding of single root templates

[AngelMunoz]

Is your feature request related to a problem? Please describe.

I get why you use subfolders right now, but if users are going to make their own templates, they probably are not going to have multiple. So the system should be flexible and allow templates from the root of a git repository, as well as from a subfolder (using a flag or so).

Describe the solution you'd like it should be possible to create templates from the root of a repository AND from repositories that have multiple directories

Describe alternatives you've considered accept only repositories with sub directories

Additional context

A brief explanation on how templates are working at the moment

1. templates are downloaded next to the perla exe/dll using github's API not GIT
   • template entries are added to a local embedded database for offline usage
2. templates then are used by the repository name + template directory in the repository
3. files are copied and if there are .tpl. files they are compiled using Scriban

I think root templates can be good, at the same time for a simplicity's and convention's based workflow I think creating a single directory template is just as viable

The inspiration for this mechanism is from makes.js and dotnet templates

I'm not entirely convinced yet to switch to root based templates yet but is worth exploring this area

cc @nojaf

[AngelMunoz]

from https://github.com/AngelMunoz/perla-samples/issues/2

[nojaf]

Thanks for considering this. I do want to state that I won't be disappointed or anything if you end up not having this.

template entries are added to a local embedded database for offline usage

Out of interest, how does this work for local tools? If for project A I add a template to the embedded database, will that project be present for project B when both are using a local tool version?

[AngelMunoz]

Out of interest, how does this work for local tools?

It works the same for both local tools and standalone binary in the case of the .NET tool it simply places the templates in a directory besides the entry DLL, in standalone tools it does the same next to the executable binary, the original idea with perla was to use it as a global tool rather than local, but if you already have a project with perla set up with it the local tool should just work as well, I'm not sure how useful is when used as a local tool

If for project A I add a template to the embedded database, will that project be present for project B when both are using a local tool version?

Yes when you add a template you add it to "perla itself" so any time you want to create another project with an existing template it just copies the previously downloaded assets, it will re-download if you use the "update" template command

Although if you update your local/global tool version I'm not sure if the .NET SDK keeps the previous files and just "patches" in the new ones or removes it completely

This was because the PoC was open a little bit more to templating in general not specifically tailored for Perla (although it did influence it quite much) If you want to explore more about the mechanism for the templates here's the original PoC: https://github.com/AngelMunoz/Clam I then incorporated that into perla, perhaps we can turn it in a project of it's own truly specialized in templating

[nojaf]

It is very likely that I have another version in project A than in project B. So I would need to add the template to both versions in order for it to be usable. The more I think this, the more I'm getting convinced that this might not really be a Perla problem but something I have. Don't be shy to abandon this request, I'm not sure about all aspects here.

[AngelMunoz]

It is very likely that I have another version in project A than in project B.

how would that be structured? do you mean for example that you want package v10.0.0 in A and package v10.1.0 in B?

meaning that you may want the version to be dynamic?

If that's the case you could use an F# script and file.tpl.ext as described here I can try to find a way to pass your current args to the fsi interpreter so you can access them in the F# script (rather than make it dynamic) and do the custom manipulation you need the templating system is supposedly designed for you to be able to customize even at the file level.

... but one thing I'm totally forgetting is that you're using it as a local tool... I'll try to do some testing around how this actually works as a local tool...

[AngelMunoz]

For the moment I don't think I've got enough resources to work towards this ticket and there doesn't seem to have traction so I will close it

I'm open to re-visit this if there's enough interest.