`dune build` should build current directory's package, not entire dune project

[mimoo]

When I'm in a specific folder in my dune project, I expect dune build to only build the package in that folder (that has a dune file)

$ pwd
/Users/davidwong/Work/mina_nix/src/lib/pickles

$ dune build
Entering directory '/Users/davidwong/Work/mina_nix'
...

The messages displayed seem to indicate that everything is being built.

I guess I would expect the same behavior with dune runtest

[rgrinberg]

Yes, because dune build is short for dune build @all. If you only want to build a particular package, you may just build $ dune build $pkg.install

[mimoo]

I think that's a bit unintuitive. There's also no way I'll be able to remember how to build a specific package : o

[rgrinberg]

The old behavior dune has similar to what you suggested. Users claimed it was also confusing because it wouldn't build anything without it being attached to a package. Rudi.

…

On Oct 24, 2022, 9:52 AM -0600, David Wong ***@***.***>, wrote: I think that's a bit unintuitive. There's also no way I'll be able to remember how to build a specific package : o — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[mimoo]

I guess this issue could be about having a more intuitive command to build the package in the current folder :o

perhaps dune build . ?

[rgrinberg]

The "package in the current folder" isn't an intuitive concept. There might be 0, 1, or many packages in the same folder. Rudi.

…

On Oct 24, 2022, 9:57 AM -0600, David Wong ***@***.***>, wrote: I guess this issue could be about having a more intuitive command to build the package in the current folder :o — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[mimoo]

btw this is what cargo would do for reference, which I find very user-friendly:

• dune build . would build all of the packages at the location (so it doesn't matter if there's 0, 1, or more)
• dune exec . would tell the user: "there are several targets: ..." and list the target names with the relevant command (e.g. dune exec ./target) so that the user can retry

[rgrinberg]

That's funny, because I find your proposal to be unfriendly. Perhaps it's a question of familiarity? Or maybe cargo does not allow targets to exist outside of packages. There's also dune build @install, which will build all the packages when it's in the root of the repo. I don't remember if it works in sub directories, but it could be worth fixing that if it doesn't. Improving the error of dune exec would certainly be a nice thing to do. Rudi.

…

On Oct 24, 2022, 10:02 AM -0600, David Wong ***@***.***>, wrote: btw this is what cargo would do for reference, which I find very user-friendly: • dune build . would build all of the packages at the location (so it doesn't matter if there's 0, 1, or more) • dune exec . would tell the user: "there are several targets: ..." and list the target names with the relevant command (e.g. dune exec ./target) so that the user can retry — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[mimoo]

Or maybe cargo does not allow targets to exist outside of packages.

What do you mean by this?

[rgrinberg]

What's the equivalent of an executable that does not belong to any package in cargo? In dune that would be: (executable  (name foo)) How do you define and build such a target in cargo? Rudi.

…

On Oct 24, 2022, 10:14 AM -0600, David Wong ***@***.***>, wrote: > Or maybe cargo does not allow targets to exist outside of packages. What do you mean by this? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[mimoo]

In cargo your stuff (library or binary (execute)) is always part of one package (declared via the Cargo.toml file which is somewhat equivalent to a dune file here).

Isn't it true for dune as well? Here you would define that executable in a dune file which would be next to a dune-project file which would have the package name?

EDIT: I guess it doesn't work like this. I'm always confused as to what exactly is a package when you start playing with both dune and opam. I was under the impression that a dune file = one package, and then you can have multiple subpackages or executables listed in there

[rgrinberg]

In my example, the executable does not belong to any package because it doesn't have a public_name nor a package field. I guess this is the source of friction. In dune, targets (such as libraries or executables) can stay unattached to any package. Such targets are deemed "private" in dune. Rudi.

…

On Oct 24, 2022, 10:19 AM -0600, David Wong ***@***.***>, wrote: In cargo your stuff (library or binary (execute)) is always part of a package. Isn't it true for dune as well? Here you would define that executable in a dune file which would be next to a dune-project file which would have the package name? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[mimoo]

I see, but so why would it be unfriendly to build all such targets when doing a dune build .?

[rgrinberg]

What do you mean it's unfriendly? The current behavior of `$ dune build .` is already to build all targets in the current directory. Therefore it would pick up the executable as well. Or do you expect it should also pick up executables in sub directories as well? Rudi.

…

On Oct 24, 2022, 10:26 AM -0600, David Wong ***@***.***>, wrote: I see, but so why would it be unfriendly to build all such targets when doing a dune build .? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[mimoo]

Oh I was reacting to your comment:

That's funny, because I find your proposal to be unfriendly

But maybe I misunderstood what you found unfriendly?

Or do you expect it should also pick up executables in sub directories as well?

I would expect that yeah (I understand that dune seems to have vague conventions regarding directory structure though). But to me dune build . should build everything it can find under the pointed location (recursively).

[mimoo]

(same for dune runtest . btw, I want to test if all tests run under some directory structure when I do this)