Implement "fpm init" to create the initial project skeleton

[certik]

It would work just like cargo init:

$ cargo init myproject1
     Created binary (application) package
$ tree -a myproject1
myproject1
├── Cargo.toml
├── .git
│   ├── config
│   ...
├── .gitignore
└── src
    └── main.rs

10 directories, 18 files

As you can see, it starts a git repository, and so on. It is ready to compile, so:

~$ cd myproject1
myproject1(master)$ cat src/main.rs 
fn main() {
    println!("Hello, world!");
}
myproject1(master)$ cargo run
   Compiling myproject1 v0.1.0 (/tmp/myproject1)
    Finished dev [unoptimized + debuginfo] target(s) in 1.25s
     Running `target/debug/myproject1`
Hello, world!

If you just call cargo init, then it creates a new project in the current directory. Similar to git init.

[everythingfunctional]

I might split the two use cases and not actually run git init.

fpm new name creates a folder name with contents fpm.toml, .gitignore and src\name.f90. Maybe app\main.f90 instead? Or maybe both? I'll come up with a specific proposal. But yeah, fpm build and maybe fpm run should work from the get go.

fpm init uses the name of the current folder as the name of the project and just creates fpm.toml. Maybe append build/* to the end of .gitignore.

I think we want people to be able to create new projects even if they don't already have git installed.

[certik]

Yes, we should allow options to configure things, so all of the above will be possible with the proper options. For example to initialize without git:

cargo init --vcs none myproject1

(Obviously you can use other vcs also such as hg.) People that do not have git can always use this option.

The default (with no options provided) should be the ones that people use the most often as well as a "default" workflow that we want to encourage. I think that we absolutely want to encourage to use git and upload to GitHub or GitLab. I think that should be the default workflow to encourage.

But for people who are perhaps new to programming and just want to use a few dependencies and write some simple app and do not want to learn git at the moment, those would initialize with git init --vcs none myproject1.

$ cargo init -h
cargo-init 
Create a new cargo package in an existing directory

USAGE:
    cargo init [OPTIONS] [--] [path]

OPTIONS:
    -q, --quiet                  No output printed to stdout
        --registry <REGISTRY>    Registry to use
        --vcs <VCS>              Initialize a new repository for the given version control system (git, hg, pijul, or
                                 fossil) or do not initialize any version control at all (none), overriding a global
                                 configuration. [possible values: git, hg, pijul, fossil, none]
        --bin                    Use a binary (application) template [default]
        --lib                    Use a library template
        --edition <YEAR>         Edition to set for the crate generated [possible values: 2015, 2018]
        --name <NAME>            Set the resulting package name, defaults to the directory name
    -v, --verbose                Use verbose output (-vv very verbose/build.rs output)
        --color <WHEN>           Coloring: auto, always, never
        --frozen                 Require Cargo.lock and cache are up to date
        --locked                 Require Cargo.lock is up to date
        --offline                Run without accessing the network
    -Z <FLAG>...                 Unstable (nightly-only) flags to Cargo, see 'cargo -Z help' for details
    -h, --help                   Prints help information

ARGS:
    <path>     [default: .]

[everythingfunctional]

I see, I was not aware of those options for cargo. With that, I'm fine with defaulting to using git. There is certainly value in having the defaults set to the most common use case and the one we want to encourage.

I would still prefer init and new as two different commands.

[milancurcic]

Cargo also has init and new. They have similar but complementary roles. I see value in having both.