Re: nested module problem

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.

Re: nested module problem

On Wed, Oct 28, 2020 at 10:52:33PM +, 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

Re: nested module problem

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

Re: nested module problem

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 `modu

Re: nested module problem

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 sour

Re: nested module problem

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 ins

Re: nested module problem

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.

Re: nested module problem

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.

Re: nested module problem

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/openmet

Re: nested module problem

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 i

Re: nested module problem

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 tha

Re: nested module problem

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.ba

Re: nested module problem

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.

Re: nested module problem

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

nested module problem

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