Enable fpm to create a new package

[everythingfunctional]

This is just the bare minimum I would say is necessary for fpm new.

[LKedward]

This looks good and works on my machine 👍

A minor observation: I expected the behaviour to be to initialise a project in the current directory (like git init), as opposed to the command creating a new directory - but I think that is just something that needs documenting somewhere for users.

[milancurcic]

I approve but this also needs to be documented in the README or elsewhere. What does it do exactly? Give an example.

A description in the PR body would help reviewers as well.

[milancurcic]

A minor observation: I expected the behaviour to be to initialise a project in the current directory (like git init), as opposed to the command creating a new directory - but I think that is just something that needs documenting somewhere for users.

This (fpm new) behaviour is analogous to cargo new, and what you describe is analogous to cargo init. So if we wanted to have this, it would be covered by fpm init.

[everythingfunctional]

Yeah, I'll add some documentation to the README, and maybe PACKAGING.md

[certik]

I believe this should be called init. Furthermore, it should initialize in the current directory without an argument, or create a new directory with an argument, just like git or Cargo. Let's keep the UI as similar to others established tools as possible.

…

On Fri, Jun 19, 2020, at 8:57 AM, Brad Richardson wrote: Yeah, I'll add some documentation to the README, and maybe PACKAGING.md — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#102 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFAWHVVJAAHKPTZZ565HTRXN4EFANCNFSM4OCLLZMQ>.

[milancurcic]

@certik, see cargo new and cargo init.

In short, cargo new (and likewise, fpm new) creates a new directory and initializes the TOML and starter source files. I think this is what this PR implements, but again, without a PR description or some example in the documentation, hard to say. @everythingfunctional can you please describe the behavior with a small example? How is this invoked? What files are created?

cargo init initializes the package in an existing directory with existing source files. So fpm init will be used to "fpm-ize" an existing package that obeys the fpm layout. fpm new is used to bootstrap a new empty package. They're different.

At least this is my understanding of it.

[milancurcic]

@everythingfunctional can you please describe the behavior with a small example? How is this invoked? What files are created?

Sorry, I didn't mean to nag. :) I saw your earlier response after writing this.

[certik]

No, cargo init creates a new package in the current directory and cargo init b creates a new package in a new directory b. I am not sure what the difference is to cargo new. But I've only used cargo init and it creates a new package from scratch.

[certik]

See #96 where I go into all the details. See also #96 (comment).

[certik]

Both cargo new and cargo init seem identical to me. They both initialize in you current directory, or in a new directory if you provide it as an argument. The initialized files seem identical. What is the difference between the two?

[milancurcic]

cargo new only creates a new directory and initializes a project in it.

cargo init initializes a project in an existing directory, and optionally does what cargo new does.

For cargo new, PATH is required. For cargo init, PATH is optional.

Indeed, if starting from scratch, they appear very much the same and redundant.

However, if there is anything special about the directory layout (multiple binaries, tests etc.) and contents that would be reflected in Cargo.toml, I would expect cargo init to do that. But I don't think it does, at least in the simple example I tried.

For fpm it should. For example, if you have a package layout with multiple programs, fpm init should be able to output a correct fpm.toml according to the special layout.

fpm new simply bootstraps something from scratch.

It's very nice and useful to use Cargo and Rust for reference, but it's not an end all. We're not targeting Rust users. What we make should make sense to us. fpm new for a new project very much makes sense, and fpm init makes more sense for initializing an existing project.

[certik]

For me it makes sense to use "fpm init" like "git init". Create a new project from scratch. I don't think by default it should do something different based on an existing project. However let's have it as an option. We should optimize for the most common use case. I think that would be to start a new project from scratch. Also, let's have only one command, init. Having two seems redundant and confusing.

…

On Fri, Jun 19, 2020, at 1:19 PM, Milan Curcic wrote: `cargo new` only creates a new directory and initializes a project in it. `cargo init` initializes a project in an existing directory, and optionally does what `cargo new` does. For `cargo new`, `PATH` is required. For `cargo init`, `PATH` is optional. Indeed, if starting from scratch, they appear very much the same and redundant. However, if there is anything special about the directory layout (multiple binaries, tests etc.) and contents that would be reflected in Cargo.toml, I would expect `cargo init` to do that. But I don't think it does, at least in the simple example I tried. For fpm it should. For example, if you have a package layout with multiple programs, `fpm init` should be able to output a correct fpm.toml according to the special layout. `fpm new` simply bootstraps something from scratch. It's very nice and useful to use Cargo and Rust for reference, but it's not an end all. We're not targeting Rust users. What we make should make sense to us. `fpm new` for a new project very much makes sense, and `fpm init` makes more sense for initializing an existing project. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#102 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFAWBLCKEQ6AJ52AAUTJLRXO24NANCNFSM4OCLLZMQ>.

[milancurcic]

For me it makes sense to use "fpm init" like "git init". Create a new project from scratch.

git init actually does not only create a new project from scratch. It initializes existing files in the directory into the git repository if there are any. It does also create a new git repository. I think it's difficult to argue that the word "init" is more intuitive for creating something new than the word "new". To me "init" means initialize, which means enable some capability in existing directory+files. In the context of fpm, that would mean simply create fpm.toml given existing pakage layout.

But I agree that we shouldn't have redundant commands like Cargo does. It looks like the choice is whether we want to have one command that does multiple things or two narrowly-scoped commands.

1. We implement just fpm init which can both create a new empty project and "fpm-ize" an existing non-fpm package (basically generate a correct fpm.toml);
2. We implement fpm new that creates an empty project and fpm init to initialize an existing package.

I think @certik prefers option 1. I prefer option 2. as it's easier to understand to me. There may be some other options I missed. @everythingfunctional @LKedward what do you prefer?

[milancurcic]

An argument for fpm init over fpm new (all else being equal) is that init is a verb and new is a noun. Using a verb would be more consistent with our existing commands (build, install, run, test), and semantically makes more sense (do this with that).

So I am not opposed to the word "init". But I do prefer smaller utility commands over more general ones that would behave differently depending on current directory.

[everythingfunctional]

Technically, giti init doesn't create a new project from scratch. It initializes an existing project's git configuration.

I like having two different commands because they do two different things. fpm new for new projects, and fpm init for existing projects.

Since the most common use case would be to start a new project from scratch, that's why I implemented it first.

[milancurcic]

Suggested change

	Creating a new fpm project is as simple as running the command `fpm new project_name`.
	Creating a new fpm project is as simple as running the command `fpm new <project-name>`.

[milancurcic]

Suggested change

	* `fpm.toml` with your project's name and some default standard meta-data
	* `fpm.toml` with your project's name and some default standard metadata

[milancurcic]

Suggested change

	* `src/project_name.f90` with a simple hello world subroutine
	* `src/<project-name>.f90` with a module containing a simple hello world subroutine

[milancurcic]

Could be tackled in a separate PR, but I suggest we use --bin instead of --with-executable (and also make it the default). Also, add an empty test program by default, as this will encourage all new projects to have tests.

[certik]

How often do you expect to initialize fpm for an existing project? I don't ever expect to do that, after I convert my existing projects. So I don't think we should optimize for this rare case. So I vote to rename new to init and we are in agreement.

…

On Fri, Jun 19, 2020, at 4:24 PM, Brad Richardson wrote: Technically, `giti init` doesn't create a new project from scratch. It initializes an existing project's git configuration. I like having two different commands because they do two different things. `fpm new` for new projects, and `fpm init` for existing projects. Since the most common use case would be to start a new project from scratch, that's why I implemented it first. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#102 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFAWFIEEUF4HMPJRLSMM3RXPQTHANCNFSM4OCLLZMQ>.

[milancurcic]

How often do you expect to initialize fpm for an existing project? I don't ever expect to do that, after I convert my existing projects.

I expect that we'll use fpm init quite often in the early days, perhaps even more often than fpm new, as we'll work hard on adapting existing Fortran packages (ours and those of others) into fpm. In the long run, I expect fpm new would be used more often.

It also depends how you're used to doing things. I never ever ran git init to create a new repo from scratch. I always run it after I've written and played with some code and want to make a git repo out of it. Same with fpm. For any more complex layout package, I'd much rather run fpm init and have fpm write the fpm.toml for me, than me editing it by hand every time I add a new file.

Even if it's an edge case and something that we'd want down the road, I think it's useful to carefully design and name things early on.

[certik]

I always indeed run "git init" on an empty repository to start a new project. Regarding adding new files, you don't modify fpm.toml when you do that.

…

On Fri, Jun 19, 2020, at 5:25 PM, Milan Curcic wrote: > How often do you expect to initialize fpm for an existing project? I don't ever expect to do that, after I convert my existing projects. I expect that we'll use `fpm init` quite often in the early days, perhaps even more often than `fpm new`, as we'll work hard on adapting existing Fortran packages (ours and those of others) into fpm. In the long run, I expect `fpm new` would be used more often. It also depends how you're used to doing things. I never ever ran git init to create a new repo from scratch. I always run it after I've written and played with some code and want to make a git repo out of it. Same with fpm. For any more complex layout package, I'd much rather run `fpm init` and have fpm write the fpm.toml for me, than me editing it by hand every time I add a new file. Even if it's an edge case and something that we'd want down the road, I think it's useful to carefully design and name things early on. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#102 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFAWDWQADEDJQCBLH5LDLRXPXVDANCNFSM4OCLLZMQ>.

[certik]

More generally, let's follow what Rust does, it's a well tested approach. Once we use it and don't like it, then let's discuss to do something else.

…

On Fri, Jun 19, 2020, at 5:52 PM, Ondřej Čertík wrote: I always indeed run "git init" on an empty repository to start a new project. Regarding adding new files, you don't modify fpm.toml when you do that. On Fri, Jun 19, 2020, at 5:25 PM, Milan Curcic wrote: > > > > How often do you expect to initialize fpm for an existing project? I don't ever expect to do that, after I convert my existing projects. > > I expect that we'll use `fpm init` quite often in the early days, > perhaps even more often than `fpm new`, as we'll work hard on adapting > existing Fortran packages (ours and those of others) into fpm. In the > long run, I expect `fpm new` would be used more often. > > It also depends how you're used to doing things. I never ever ran git > init to create a new repo from scratch. I always run it after I've > written and played with some code and want to make a git repo out of > it. Same with fpm. For any more complex layout package, I'd much rather > run `fpm init` and have fpm write the fpm.toml for me, than me editing > it by hand every time I add a new file. > > Even if it's an edge case and something that we'd want down the road, I > think it's useful to carefully design and name things early on. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#102 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAAFAWDWQADEDJQCBLH5LDLRXPXVDANCNFSM4OCLLZMQ>. >

[everythingfunctional]

I honestly didn't even know that git init directory was a valid command. I learned something new today! I always thought you just had to git init inside a directory, existing files or not.

I still think that the command that makes the most sense for creating a new project is fpm new, even if that's not what Cargo does. Although I will note the following output from cargo, which would seem to suggest that cargo somewhat agrees with me. cargo new is for a new cargo package and cargo init is for in an existing directory.

[darter:~] cargo help new
cargo-new 
Create a new cargo package at <path>

USAGE:
    cargo new [OPTIONS] <path>

[darter:~] cargo help init
cargo-init 
Create a new cargo package in an existing directory

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

[certik]

Here is the guide for Cargo:

https://doc.rust-lang.org/cargo/guide/creating-a-new-project.html

it seems they recommend cargo new also.

I explained my position above, Milan and Brad explained theirs, and it looks like they prefer to use fpm new instead of fpm init to start a new package. So unless more people have an opinion right now, let's go with fpm new and move on.

However, I reserve the right to run a poll later on, and if more people prefer fpm init, let's reconsider. Until then, let's do fpm new.

[milancurcic]

However, I reserve the right to run a poll later on, and if more people prefer fpm init, let's reconsider. Until then, let's do fpm new.

Definitely, we don't have a majority agreement right now.