Initialize new project in current directory

[Ajlow2000]

Desired Behavior

I would like to be able to run dune init proj NAME and have it create my project in place (ie, not a subdirectory ./NAME).

Current Behavior / Problem Space

Currently dune init proj NAME requires a NAME parameter and creates a subdirectory. Every time I've used dune to initialize a project, I am starting from an empty git repo, and running dune from the repo's root. This creates the dune project nested down a level which I don't want. I work around this by moving the contents of the newly created subdirectory up to the repo's root, and then deleting the now empty ./NAME directory that was created by dune. This is uncomfortable for someone who's new to the language and is spinning up new projects that are very small in scope just to learn (ie: me).

Example

Intended functionality would be similar to nix flake initi.
Example workflow for initializing project:

# Create a new bare repo on github.com
git clone my/repo
nix flake init # included to show how I expected dune to work
dune init proj MY_PROJ --in-place
# write some ocaml

Initial Considerations

My initial intuition when using dune was just to run dune init proj (omitting the name parameter) as this is how other tooling like nix flake init works. Because the name parameter gets used for more then just the path in which to create the dune project, my suggestion is to add an optional flag that specifies that I want my dune project created in-place. Something like --in-place is narrow in scope and behavior, or --path=/my/custom/path which could give more flexibility to the tool at the cost of intuitiveness.

[nojb]

+1 for this suggestion; I also found the NAME behaviour unintuitive. The suggestion matches the behaviour of git, for example (where git init initializes a repository the current directory).

[yawaramin]

Another idea: dune init proj . which should work similarly to git init . i.e. initialize the component using the name of the current directory.

[nojb]

Another idea: dune init proj . which should work similarly to git init . i.e. initialize the component using the name of the current directory.

Sounds like a good idea to me.

[Ajlow2000]

Worth noting how cargo does this: https://doc.rust-lang.org/cargo/commands/cargo-init.html#examples

Create a binary Cargo package in the current directory:
cargo init

I havent dug into src, but I imagine it uses the current directory as the project name. I like the explicitness of @yawaramin suggestion though.

[Ajlow2000]

Another idea: dune init proj . which should work similarly to git init . i.e. initialize the component using the name of the current directory.

Thought: Dashes (-) in filenames are perfectly valid, but currently get rejected from dune init proj NAME. Combine that with the fact that best practices with naming git repos using dashes over underscores (my understanding is this is due to readability in urls), and things get a bit convoluted. I suppose this case doesn't necessary need handled as it might be out scope, but it warrants a comment at least.

[shonfeder]

Here's the commands help currently:

NAME
       dune-init - Command group for initializing dune components

SYNOPSIS
       dune init proj NAME [PATH] [OPTION]...
       dune init exec NAME [PATH] [OPTION]...
       dune init lib NAME [PATH] [OPTION]...
       dune init test NAME [PATH] [OPTION]...

DESCRIPTION
       dune init COMPONENT NAME [PATH] [OPTION]... initializes a new dune
       configuration for a component of the kind specified by the subcommand
       COMPONENT, named NAME, with fields determined by the supplied OPTIONs.

       Run a subcommand with  --help for for details on it's supported
       arguments

       If the optional PATH is provided, the component will be created there.
       Otherwise, it is created in the current working directory.

Using the optional PATH argument currently works like this:

$ dune init proj myproj foo/bar/baz
Entering directory '$PWD/foo/bar/baz/myproj'
Success: initialized project component named myproj

Making the first positional argument sometimes act like a project name and sometimes be inferred as a directory would conflict with this behavior. This is in addition to the conflict @Ajlow2000 notes with naming constraints. There is also possible ambiguity if a directory of the same name were present when you meant to just supply a name. Given these complications, I think @yawaramin's suggestion may be impracticable.

cargo init makes sense in the context of cargo because they also have cargo new (I initially wanted project template creation to be under a new subcommand, following this example. See, e.g., #159 (comment)).

I like @Ajlow2000's suggestion of --in-place, but will also propose these possible options:

1. At the price of a tiny breaking change, we can change the behavior of the optional PATH argument so that it work as @Ajlow2000 suggested for the --path flag. Currently, we add a new directory at the end of the given PATH, but this makes dune init proj foo . equivalent to dune init proj foo. Instead, if a path is given, we can create the assents in the named directory. This is arguably more intuitive.
2. At the price of a bigger breaking change, we can rework the CLI to use new and init subcommands, adopting the idiom used by cargo (and poetry).

I like the idea of (1) ok, actually. WDYT?

[yawaramin]

I tried out (1) and actually I think there is a small discrepancy between how the two variants should behave based on common sense understanding:

dune init proj foo .

This creates a new project in a subdirectory foo.

dune init proj foo foo

This creates a new project in a subdirectory foo.

The second behaviour makes sense. But then, in those terms, the first behaviour does not make sense. If we specify a path foo and dune creates a subdirectory foo, then it should not also create a subdirectory if we specify the current directory ..

I think this should be changed so that the first command should create the project in place in the current directory.

[shonfeder]

Good find! Given that inconsistency, I think it is arguable that the current behavior is erroneous. We can implement (1) as a bug fix, and add a line to the docs noting how to initialize a project in the current directory.

Any objections, concerns, or better ideas?

[Alizter]

I personally think its ok to change the behaviour of dune init in a non-backwards-compatible way if it means new users have a better experience. I think its probably worth discussing in the next Dune meeting however.

[shonfeder]

I'd support that, @Alizter. We have a lot of feedback to draw from, as well as other mature tools we can take inspiration from at this point.

Following up on @Ajlow2000's point about cargo behavior, it does indeed infer the name from the parent dir, and just raises in error if is invalid:

$ cd '=__--*'/
$ cargo init
error: invalid character `=` in crate name: `=__--*`, the first character must be a Unicode XID start character (most letters or `_`)
use --name to override crate name

cargo new also doesn't differentiate between a path and the package name:

$ cargo new foo/bar/baz
     Created binary (application) `foo/bar/baz` package
$ rg name foo/bar/baz/Cargo.toml
2:name = "baz"

It addresses the ambiguity I was concerned with by just signaling an error if a directory already exists with the same name as intended project.