You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea of creating a .net project, having to change directories into that project, then building the project, is a workflow that is foreign to some of our early adopters. For these early adopters, the whole project setup and build pipeline is currently handled by Visual Studio.
The CLI doesn't have to do as much work in hypar new. Currently, there is bootstrapping code in the new command which creates a project and a default class file. This can be replaced with a github repository that has everything a starter project needs. We didn't do this initially for fear that having github as a dependency would be a stumbling block. But it seems that some early adopters are more comfortable using github (most likely through the GUI) than they are using the command line.
The workflow would therefore look like this:
User does git clone https://github.com/hypar-io/dotnet-starter or git clone https://github.com/hypar-io/python-starter.
For a .net project, the user opens Visual Studio and opens the created .sln file. They can build and test from Visual Studio.
For dotnet, the starter project could also have the Hypar CLI as a build tool, so we wouldn't have to distribute the CLI using a zip.
The CLI's new command has been updated to clone from the starter repo. The user can now do hypar new foo and the starter repo will be cloned into foo ready to publish :)
The idea of creating a .net project, having to change directories into that project, then building the project, is a workflow that is foreign to some of our early adopters. For these early adopters, the whole project setup and build pipeline is currently handled by Visual Studio.
The CLI doesn't have to do as much work in
hypar new
. Currently, there is bootstrapping code in the new command which creates a project and a default class file. This can be replaced with a github repository that has everything a starter project needs. We didn't do this initially for fear that having github as a dependency would be a stumbling block. But it seems that some early adopters are more comfortable using github (most likely through the GUI) than they are using the command line.The workflow would therefore look like this:
git clone https://github.com/hypar-io/dotnet-starter
orgit clone https://github.com/hypar-io/python-starter
.For dotnet, the starter project could also have the Hypar CLI as a build tool, so we wouldn't have to distribute the CLI using a zip.
@MarkThorley
The text was updated successfully, but these errors were encountered: