www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - nested module problem

reply Jean-Louis Leroy <jl leroy.nyc> writes:
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?
Sep 02 2017
next sibling parent reply Moritz Maxeiner <moritz ucworks.org> writes:
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
Sep 02 2017
parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
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.
Sep 02 2017
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
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
Sep 02 2017
parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
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...
Sep 02 2017
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
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)?
Sep 02 2017
parent Moritz Maxeiner <moritz ucworks.org> writes:
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
Sep 02 2017
prev sibling next sibling parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
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.
Dec 24 2017
next sibling parent =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
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>
Dec 24 2017
prev sibling parent Jean-Louis Leroy <jl leroy.nyc> writes:
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!
Dec 25 2017
prev sibling parent reply mw <mingwu gmail.com> writes:
I run into a similar issue today:

-- I try to use a library `pyd`, and
-- my local project has a file called "source/util.d"

the dub build error out:

/.dub/packages/pyd-0.13.1/pyd/infrastructure/util/typelist.d(1,1): Error:
package name 'util' conflicts with usage as a module name in file source/util.d


I wonder what's the best way to resolve this conflict, i.e my 
local file name with 3rd party library dir name.
Oct 28 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 28 October 2020 at 22:43:12 UTC, mw wrote:

 I wonder what's the best way to resolve this conflict, i.e my 
 local file name with 3rd party library dir name.


Don't write any module with a single name unless you are 
guaranteed to never import it.

pyd should have called it like `module pyd.util;`

Then you call yours like `module mw.util;`

This makes such conflicts a lot less likely.
Oct 28 2020
next sibling parent mw <mingwu gmail.com> writes:
On Wednesday, 28 October 2020 at 22:52:33 UTC, Adam D. Ruppe 
wrote:

 On Wednesday, 28 October 2020 at 22:43:12 UTC, mw wrote:

 I wonder what's the best way to resolve this conflict, i.e my 
 local file name with 3rd party library dir name.


 Don't write any module with a single name unless you are 
 guaranteed to never import it.

 pyd should have called it like `module pyd.util;`

 Then you call yours like `module mw.util;`

 This makes such conflicts a lot less likely.



Thanks for the tip, Adam.


And I fixed the imports in multiple files with:

```
$ sed -i 's/import util;/import mw.util;/g' *.d
```

Hope this will help if someone else also run into this issue.
Oct 28 2020
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 28, 2020 at 10:52:33PM +0000, Adam D. Ruppe via Digitalmars-d-learn
wrote:

 On Wednesday, 28 October 2020 at 22:43:12 UTC, mw wrote:

 I wonder what's the best way to resolve this conflict, i.e my local
 file name with 3rd party library dir name.


 
 Don't write any module with a single name unless you are guaranteed to
 never import it.
 
 pyd should have called it like `module pyd.util;`
 
 Then you call yours like `module mw.util;`
 
 This makes such conflicts a lot less likely.


IMO, 3rd party libraries should always be in their own package
namespace. Leave the top-level for user code! Why should a local module
'util' conflict with any dependency?  It should be the library author's
job to make sure his code doesn't conflict with the user's!


T

-- 
Recently, our IT department hired a bug-fix engineer. He used to work for
Volkswagen.
Oct 28 2020
parent mw <mingwu gmail.com> writes:
 IMO, 3rd party libraries should always be in their own package 
 namespace. Leave the top-level for user code! Why should a 
 local module 'util' conflict with any dependency?  It should be 
 the library author's job to make sure his code doesn't conflict 
 with the user's!


logged:

https://github.com/ariovistus/pyd/issues/140
Oct 28 2020