Add new command support

[damon-kwok]

Add new command support for corral

There is already an init command, why is it superfluous?
It is the premise of adding template system to corral.

corral new hello

It looks like this logic：

mkdir hello
cd hello
corral init

The final new command:

corral new <template> mylib

results:

hello
├── corral.json
├── CHANGELOG.md
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── examples
│   └── simple-example
│       └── simple-example.pony
├── gitattributes
├── gitignore
├── hello
│   └── _test.pony
├── LICENSE
├── Makefile
├── README.md
├── RELEASE_PROCESS.md
└── STYLE_GUIDE.md

[SeanTAllen]

This is something we've discussed. Rolling the scaffolding packages into corral.

Do you have ideas on how this would be implemented?

[damon-kwok]

Do you have ideas on how this would be implemented?

Yes.It looks like Leiningen's template system:
https://github.com/technomancy/leiningen/blob/master/doc/TEMPLATES.md

[SeanTAllen]

Are you saying it is a direct copy? Everything will be exactly the same? "looks like" suggests differences.

I'd like to see a write up of how the templating would work for corral, not "looks like" something else.

The process of doing the design for corral will likely expose dependencies and other issues that will need to be discussed and worked through.

[damon-kwok]

Not a simple copy. When a project is created using a template, it will automatically download the dependencies specified in corral.json.

[damon-kwok]

corral.json is part of the template, the author of the template has built in the required dependency information

[SeanTAllen]

Not a simple copy. When a project is created using a template, it will automatically download the dependencies specified in corral.json.

I dont understand

corral.json is part of the template, the author of the template has built in the required dependency information

I don't understand.

[damon-kwok]

For example:

corral new <templete> hello

You will get this directory:

hello
├── corral.json
├── CHANGELOG.md
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── examples
│   └── simple-example
│       └── simple-example.pony
├── gitattributes
├── gitignore
├── hello
│   └── _test.pony
├── LICENSE
├── Makefile
├── README.md
├── RELEASE_PROCESS.md
└── STYLE_GUIDE.md

Its corral.json content is:

{
  "deps": [
    {
      "locator": "github.com/mfelsche/ponycheck.git",
      "version": "0.5.4"
    },
    {
      "locator": "github.com/ponylang/valbytes.git",
      "version": "0.5.0"
    },
    {
      "locator": "github.com/ponylang/net_ssl.git",
      "version": "1.0.0"
    }
  ],
  "info": {}
}

[SeanTAllen]

I don't understand what your replies have to do with how the templating would work.

[damon-kwok]

To put it simply: initialize a pony project with a specific structure and automatically download dependencies.

[SeanTAllen]

To put it simply: initialize a pony project with a specific structure and automatically download dependencies.

This reply has as far as I can tell nothing to do with what I asked. But I see where the confusion is so let me try again:

Are you saying this will be a is a direct copy of how leingein works? Everything will be exactly the same? You siad "looks like" suggests differences.

I'd like to see a write up of how the templating would work for corral, not "looks like" something else.

The process of doing the design for corral will likely expose dependencies and other issues that will need to be discussed and worked through.

[damon-kwok]

Yes, it will be a is a direct copy of how Leiningen works.
I think the meaning of the template system is to help people quickly clone an existing engineering structure style.

[damon-kwok]

About templates, I think the problems of corral and lein are similar. We can learn from its ideas.

[rhagenson]

I absolutely this Corral should have a new command to encompass the library scaffolding.

I see this similar to but not the same as lein. From reading the lein docs it appears that what it does is use Mustache for templating and replaces Mustache variables with their values. My foreseen problem is how to handle variables without values? If arbitrary templates are allowed then so to are arbitrary variables.

I think a more limited design is best at this point and we can expand as needed.

---

My alternative proposal is mostly to do what the library scaffolding does currently, but in Pony rather than BASH. We limited the allowed variables to those currently available here and reuse the templates already available in the library scaffolding generator src/ directory.

The improvement I would make beyond the library scaffolding is adding more options in the form choices to use stable versus corral and ghactions versus circleci.

So the command might be used as corral new myproject --ci=ghactions --deps=corral to get a myproject using GitHub Actions and corral init ran in the new directory.

The more user-centric variables (i.e., GITHUB_USER and COMMIT_EMAIL) would be set as a corral new config stored at ~/.corral/config/new.toml.

This would then perhaps require an addition configuration command used like corral config GITHUB_USER=rhagenson

We would need to determine what a minimum configuration looks like and what a local override then looks like. Alternatively we can drastically pare down functionality and go more of the cargo route where corral new myproject would do little more than build a directory called myproject with a src/main.pony and corral.json file. Fewer options, fewer fluff, and fewer problems to start. Any additional features such as pre-configured CI could be added manually or rolled into corral new at a later point in time.

---

My vote as a hopeful individual is the proposal above to roll all of the library scaffolding into a corral new, but my internal "hold your horses" says make it as minimal as possible now and expand as needed. I have used the library scaffolding many times and I would not have included CI for most of the projects I started -- they were for my use so I was not going to use CI anyhow until I had at least written a handful of tests worthy of having validated on new commits.