So I have:

jll@ORAC:~/dev/d/tests/modules$ tree
.
├── foo
│   └── bar.d
└── foo.d

foo.d contains:
import foo.bar;

bar.d is empty.

Now I try compiling:
jll@ORAC:~/dev/d/tests/modules$ dmd -c foo.d
jll@ORAC:~/dev/d/tests/modules$ dmd -c foo/bar.d

So far so good. Now I try it the way dub does it:
jll@ORAC:~/dev/d/tests/modules$ dmd -c foo.d foo/bar.d
foo.d(1): Error: module bar from file foo/bar.d must be imported with 'import bar;'

What's up?

On Saturday, 2 September 2017 at 20:03:48 UTC, Jean-Louis Leroy wrote:
> So I have:
>
> jll@ORAC:~/dev/d/tests/modules$ tree
> .
> ├── foo
> │   └── bar.d
> └── foo.d
>
> foo.d contains:
> import foo.bar;
>
> bar.d is empty.

This means bar.d's module name will be inferred by the compiler [1], which will ignore the path you put it under, yielding the module name "bar", not "foo.bar" (one of the issues of doing otherwise would be how the compiler should know at which path depth the inference should start - and any solution to that other than simply ignoring the path would be full of special cases):

>> Modules have a one-to-one correspondence with source files. The module name is, by default, the file name with the path and extension stripped off, and can be set explicitly with the module declaration.

>
> Now I try compiling:
> jll@ORAC:~/dev/d/tests/modules$ dmd -c foo.d

This looks like a compiler bug to me (accepts invalid), though I'm not certain.

> jll@ORAC:~/dev/d/tests/modules$ dmd -c foo/bar.d

(No issue here, just an empty module being compiled separately)

>
> So far so good. Now I try it the way dub does it:
> jll@ORAC:~/dev/d/tests/modules$ dmd -c foo.d foo/bar.d
> foo.d(1): Error: module bar from file foo/bar.d must be imported with 'import bar;'
>
> What's up?

This doesn't work, because of the inferred module name for foo/bar.d being "bar".
So the compiler wants you to import it by the name it has inferred for you (The fix being either specifying the module name in foo/bar.d as `module foo.bar`, or importing it as via `import bar;` in foo.d).
[1] https://dlang.org/spec/module.html

On Saturday, 2 September 2017 at 20:48:22 UTC, Moritz Maxeiner wrote:
> So the compiler wants you to import it by the name it has inferred for you (The fix being either specifying the module name in foo/bar.d as `module foo.bar`, or importing it as via `import bar;` in foo.d).
> [1] https://dlang.org/spec/module.html

I thought of doing that, it merely changed the error. OK now I have:

in foo.d:
module foo;
import foo.bar;

in foo/bar.d:
module foo.bar;

$ dmd -c foo.d foo/bar.d
foo/bar.d(1): Error: package name 'foo' conflicts with usage as a module name in file foo.d

If I compile separately:
jll@ORAC:~/dev/d/tests/modules$ dmd -I. -c foo.d
foo/bar.d(1): Error: package name 'foo' conflicts with usage as a module name in file foo.d
jll@ORAC:~/dev/d/tests/modules$ dmd -I. -c foo/bar.d

It believes that 'foo' is a package...because there is a 'foo' directory?

I see that a workaround is to move foo.d to foo/package.d but I would like to avoid that.

On Saturday, 2 September 2017 at 21:24:19 UTC, Jean-Louis Leroy wrote:
> On Saturday, 2 September 2017 at 20:48:22 UTC, Moritz Maxeiner wrote:
>> So the compiler wants you to import it by the name it has inferred for you (The fix being either specifying the module name in foo/bar.d as `module foo.bar`, or importing it as via `import bar;` in foo.d).
>> [1] https://dlang.org/spec/module.html
>
> I thought of doing that, it merely changed the error. OK now I have:
>
> in foo.d:
> module foo;
> import foo.bar;
>
> in foo/bar.d:
> module foo.bar;
>
> $ dmd -c foo.d foo/bar.d
> foo/bar.d(1): Error: package name 'foo' conflicts with usage as a module name in file foo.d
>
> If I compile separately:
> jll@ORAC:~/dev/d/tests/modules$ dmd -I. -c foo.d
> foo/bar.d(1): Error: package name 'foo' conflicts with usage as a module name in file foo.d

Yes, these now both fail because you cannot have a module `foo` and a package `foo` at the same time (they share a namespace), I forgot about that.

> jll@ORAC:~/dev/d/tests/modules$ dmd -I. -c foo/bar.d

(same as before, no issue here)

>
> It believes that 'foo' is a package...because there is a 'foo' directory?

You created the 'foo' package by specifying `module foo.bar` in foo/bar.d.

>
> I see that a workaround is to move foo.d to foo/package.d but I would like to avoid that.

AFAIK you can't; consider:

-- baz.d ---
import foo;
------------

in the same directory as foo.d. If foo/package.d exists (with `module foo` inside), what should baz.d import? foo.d or foo/package.d?
The point being that we could have either used foo/package.d or foo.d for a package file, but not both (as that would allow ambiguity) and package.d was chosen.

[1] https://dlang.org/spec/module.html#package-module

On Saturday, 2 September 2017 at 21:42:59 UTC, Moritz Maxeiner wrote:
> On Saturday, 2 September 2017 at 21:24:19 UTC, Jean-Louis Leroy wrote:
>> [...]
>
> Yes, these now both fail because you cannot have a module `foo` and a package `foo` at the same time (they share a namespace), I forgot about that.
>
>> [...]
>
> (same as before, no issue here)
>
>> [...]
>
> You created the 'foo' package by specifying `module foo.bar` in foo/bar.d.
>
>> [...]
>
> AFAIK you can't; consider:
>
> -- baz.d ---
> import foo;
> ------------
>
> in the same directory as foo.d. If foo/package.d exists (with `module foo` inside), what should baz.d import? foo.d or foo/package.d?
> The point being that we could have either used foo/package.d or foo.d for a package file, but not both (as that would allow ambiguity) and package.d was chosen.
>
> [1] https://dlang.org/spec/module.html#package-module

Hmmm I see...I was thinking of spinning the runtime part of my openmethods library into its own module (like here https://github.com/jll63/openmethods.d/tree/split-runtime/source/openmethods) but it looks like a bad idea...

On Saturday, 2 September 2017 at 21:56:15 UTC, Jean-Louis Leroy wrote:
> [...]
>
> Hmmm I see...I was thinking of spinning the runtime part of my openmethods library into its own module (like here https://github.com/jll63/openmethods.d/tree/split-runtime/source/openmethods) but it looks like a bad idea...

Why does it look like a bad idea (I don't see an immediate issue the module structure either way)?

On Saturday, 2 September 2017 at 23:02:18 UTC, Moritz Maxeiner wrote:
> On Saturday, 2 September 2017 at 21:56:15 UTC, Jean-Louis Leroy wrote:
>> [...]
>>
>> Hmmm I see...I was thinking of spinning the runtime part of my openmethods library into its own module (like here https://github.com/jll63/openmethods.d/tree/split-runtime/source/openmethods) but it looks like a bad idea...
>
> Why does it look like a bad idea (I don't see an immediate issue the module structure either way)?

* in the module structure

On Saturday, 2 September 2017 at 20:03:48 UTC, Jean-Louis Leroy wrote:
> jll@ORAC:~/dev/d/tests/modules$ tree
> .
> ├── foo
> │   └── bar.d
> └── foo.d

I think that shouldn't be allowed. You have a package foo, but use a normal module instead of foo/package.d. I'm going to file a bug on that.

On Sunday, 24 December 2017 at 22:17:23 UTC, Luís Marques wrote:
> I think that shouldn't be allowed. You have a package foo, but use a normal module instead of foo/package.d. I'm going to file a bug on that.

<https://issues.dlang.org/show_bug.cgi?id=18123>

On Sunday, 24 December 2017 at 22:17:23 UTC, Luís Marques wrote:
> On Saturday, 2 September 2017 at 20:03:48 UTC, Jean-Louis Leroy wrote:
>> jll@ORAC:~/dev/d/tests/modules$ tree
>> .
>> ├── foo
>> │   └── bar.d
>> └── foo.d
>
> I think that shouldn't be allowed. You have a package foo, but use a normal module instead of foo/package.d. I'm going to file a bug on that.

Monkey testing haha!