Consider updating package project template to follow release automation infrastructure

[glopesdev]

Following the changes to project infrastructure introduced in #1873 it might be a good idea to update the package project template to align with some of the modern patterns we adopted for .csproj files.

Specifically I was thinking of adopting artifacts output layout for all packages, but maybe there are some other ideas which could be easily ported over.

[PathogenDavid]

On one hand I feel like project templates should be relatively unopinionated, on the other hand people making Bonsai extensions might not necessarily be super in-tune with .NET best practices so this is a good way to introduce them.

Definitely open to looking through things and look for good candidates for things to add.

Specifically I was thinking of adopting artifacts output layout for all packages

One issue with artifacts output layout in particular is that it relies on the presence of a Directory.Build.props to determine the default ArtifactsPath location.

I've not messed with .NET templates much, but Directory.Build.props is outside of any individual project so I'm not sure if it's something we could/should create? If it's possible to add it only when creating a fresh solution that'd be reasonable though.

[glopesdev]

One issue with artifacts output layout in particular is that it relies on the presence of a Directory.Build.props to determine the default ArtifactsPath location.

Ah, that is indeed a pity. I was hoping there would be a reasonable default location, but in that case yeah I wouldn't mess with it, we can review this again more carefully for next release.

Leaving here a link to the Artifacts output layout docs for future reference.

[PathogenDavid]

One thought if we want to go full opinionated recommended-practices guidance template is we could provide a GitHub Template instead. I don't personally love them but they're basically intended for this sort of thing.

If we wanted to help people get started with GitHub Actions this would also be more ideal for that since that's something that really lives outside of the project.

Here's an example of a GitHub Template if you've never interacted with one before: https://github.com/actions/typescript-action

Basically you click the "Use Template" button and it creates a new repo initialized with the contents of that repo. It's not quite the same as a fork since the history of the template is lost and the repo stands on its own as far as GitHub is concerned. (There is a permanent ugly little note saying it was generated from a template though. -- Here's an example instantiation of that template.)

[bruno-f-cruz]

I have had generally bad experiences with templates in the past. The idea is cute but always feel like they are hard to maintain and update downstream. I have been looking into cookiecutter as an alternative. Some people have used it for dotnet projects. Any thoughts?

Edit: something like this? https://github.com/taylorgoodallau/cookiecutter-dotnet-console

[PathogenDavid]

update downstream

Yeah, this was something that came across my mind when I mentioned GitHub Templates. I think the idea though is that projects are expected to typically diverge from the original template too much for this to ever be super useful, but it definitely is potentially a bit unfortunate in our scenario.

Any thoughts?

Cookiecutter is not something I've seen before, definitely looks interesting but I'm not super sure I love the idea of asking people to install Python just to instantiate a template for a Bonsai project.

That being said I am 1000% not the target audience of these templates so I don't have super strong opinions about them in general.

[bruno-f-cruz]

That's a fair point.

Coming back to the dotnet templates. If the only file missing is the .props, couldn't we just fetch it from a maintained template via a simple powershell script during the template deployment? I am not familiar with developing these templates so I may be missing something.

[glopesdev]

Even easier you can just run dotnet new buildprops --use-artifacts and it should be enough.

But ideally I would like to avoid powershell and see if we can get away with just some weird dotnet new arcana (they support so many random useless things and yet miss so many other really important basics that you never know; the templating system is basically a great example of why JSON is not a good idea for programming languages or even more general DSLs...).

[ncguilbeault]

I realize my previous comment was a bit off topic, but regarding the project template, it could be interesting to explore whether templates can be configured differently depending on the OS, and whether this fits with .NET standards. For example, right now the launchSettings.json file is Windows OS specific, but if it could be configured to launch bonsai through running VS code on Linux, this would be very useful for people developing on non Windows OSs.