I have different versions of a library module in different folders. For example

/version1/lib.d
/version2/lib.d

In my application I need to be able to update the names of the different folders without needing to change the module files. That means the file cannot contain "module version1.lib;" since I may need to change it to "versionA".

Ideally, I want to omit the "module" declaration in the library file, but still import it with the desired file path as "import version1.lib;".  And I would also want to "import version2.lib;" without conflict.

Basically, I want the namespace of the identifiers in the library module to be defined by the path which is use to load them *without needing to put the path in the module file.*  Is there some way to do this?

On Monday, 24 October 2016 at 21:06:18 UTC, Jeff Thompson wrote:
> I have different versions of a library module in different folders. For example
>
> /version1/lib.d
> /version2/lib.d
>
> In my application I need to be able to update the names of the different folders without needing to change the module files. That means the file cannot contain "module version1.lib;" since I may need to change it to "versionA".
>
> Ideally, I want to omit the "module" declaration in the library file, but still import it with the desired file path as "import version1.lib;".  And I would also want to "import version2.lib;" without conflict.
>
> Basically, I want the namespace of the identifiers in the library module to be defined by the path which is use to load them *without needing to put the path in the module file.*  Is there some way to do this?

Not sure if I understand you correctly, but you're allowed to omit the module declaration, if that helps:

https://dlang.org/spec/module.html#module_declaration

"The ModuleDeclaration sets the name of the module and what package it belongs to. If absent, the module name is taken to be the same name (stripped of path and extension) of the source file name."

On Monday, 24 October 2016 at 23:26:09 UTC, bitwise wrote:
> Not sure if I understand you correctly, but you're allowed to omit the module declaration, if that helps:

It doesn't help, I strongly recommend you ALWAYS use the explicit module definition. If you leave it out, you'll regret it sooner or later.

The automatic module name never has a package component, it is just one word, and is thus highly likely to cause name conflicts later.

On Monday, 24 October 2016 at 21:06:18 UTC, Jeff Thompson wrote:
> Basically, I want the namespace of the identifiers in the library module to be defined by the path which is use to load them *without needing to put the path in the module file.*  Is there some way to do this?

That's not going to work... but why do you want this? If they are different versions of the file, editing the module definition should be no real problem. You can use renamed imports or a helper module with public import to keep user code more compatible.

You can also do the opposite easily: have several files all with the same module name, but pick the specific path you want on the command line. Just make two files, v1.d and v2.d, both with `module myproject.myfile;` and import it as `import myproject.myfile;`

When compiling, then just do `dmd yourcode.d v1.d` or `dmd yourcode.d v2.d` to pick the one you want.

On Tuesday, 25 October 2016 at 00:42:59 UTC, Adam D. Ruppe wrote:
> On Monday, 24 October 2016 at 21:06:18 UTC, Jeff Thompson wrote:
>> Basically, I want the namespace of the identifiers in the library module to be defined by the path which is use to load them *without needing to put the path in the module file.*  Is there some way to do this?
>
> That's not going to work... but why do you want this? If they are different versions of the file, editing the module definition should be no real problem. You can use renamed imports or a helper module with public import to keep user code more compatible.

A variant of this is where the version name is the Git commit hash. Instead of "version1" and "version2" it is:

/commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94/lib.d
/commit_df0741a84c8a967ea08674090afdff4e9a58d23e/lib.d

The file lib.d can't contain its own commit hash, so I can't put it in the module declaration. And different parts of the application rely on different versions so I need different application files to be able to import one or the other without conflict. I'm trying to escape the situation where a piece of code needs to know the path which the operating system uses to load it.

On Tuesday, 25 October 2016 at 06:47:14 UTC, Jeff Thompson wrote:
> On Tuesday, 25 October 2016 at 00:42:59 UTC, Adam D. Ruppe wrote:
>> [...]
>
> A variant of this is where the version name is the Git commit hash. Instead of "version1" and "version2" it is:
>
> /commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94/lib.d
> /commit_df0741a84c8a967ea08674090afdff4e9a58d23e/lib.d
>
> The file lib.d can't contain its own commit hash, so I can't put it in the module declaration. And different parts of the application rely on different versions so I need different application files to be able to import one or the other without conflict. I'm trying to escape the situation where a piece of code needs to know the path which the operating system uses to load it.

Sorry if I didn't understand something, couldn't you do this?

/commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94/version/lib.d
/commit_df0741a84c8a967ea08674090afdff4e9a58d23e/version/lib.d

On Tuesday, 25 October 2016 at 19:54:42 UTC, Jonathan Marler wrote:
> On Tuesday, 25 October 2016 at 06:47:14 UTC, Jeff Thompson wrote:
>> [...]
>
> Sorry if I didn't understand something, couldn't you do this?
>
> /commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94/version/lib.d
> /commit_df0741a84c8a967ea08674090afdff4e9a58d23e/version/lib.d

If I do that, can lib.d avoid the following module statement?
module commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94.version.lib

On Tuesday, 25 October 2016 at 22:25:51 UTC, Jeff Thompson wrote:
> On Tuesday, 25 October 2016 at 19:54:42 UTC, Jonathan Marler wrote:
>> On Tuesday, 25 October 2016 at 06:47:14 UTC, Jeff Thompson wrote:
>>> [...]
>>
>> Sorry if I didn't understand something, couldn't you do this?
>>
>> /commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94/version/lib.d
>> /commit_df0741a84c8a967ea08674090afdff4e9a58d23e/version/lib.d
>
> If I do that, can lib.d avoid the following module statement?
> module commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94.version.lib

dmd -I/commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94/version/ main.d
dmd -I//commit_df0741a84c8a967ea08674090afdff4e9a58d23e/version/ main.d

On Wednesday, 26 October 2016 at 01:15:02 UTC, Mike Parker wrote:
> On Tuesday, 25 October 2016 at 22:25:51 UTC, Jeff Thompson wrote:
>> On Tuesday, 25 October 2016 at 19:54:42 UTC, Jonathan Marler wrote:
>>> On Tuesday, 25 October 2016 at 06:47:14 UTC, Jeff Thompson wrote:
>>>> [...]
>>>
>>> Sorry if I didn't understand something, couldn't you do this?
>>>
>>> /commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94/version/lib.d
>>> /commit_df0741a84c8a967ea08674090afdff4e9a58d23e/version/lib.d
>>
>> If I do that, can lib.d avoid the following module statement?
>> module commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94.version.lib
>
> dmd -I/commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94/version/ main.d
> dmd -I//commit_df0741a84c8a967ea08674090afdff4e9a58d23e/version/ main.d

This will force the application to use either one version or the other. As I said, it's a large application. I different parts of the same application to be able to import the version they need.

On Wednesday, 26 October 2016 at 07:14:30 UTC, Jeff Thompson wrote:

>>
>> dmd -I/commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94/version/ main.d
>> dmd -I//commit_df0741a84c8a967ea08674090afdff4e9a58d23e/version/ main.d
>
> This will force the application to use either one version or the other. As I said, it's a large application. I different parts of the same application to be able to import the version they need.

A module named foo.bar is foo.bar. There's no way to have a foo.bar version1 and a foo.bar version2 in the same program. You compile and link one version or the other, period. If you want multiple versions in the same program, then they need to have distinct module names:

foo/bar1.d --> module foo.bar1;
foo/bar2.d --> module foo.bar2;

I can't see how you would expect it to work otherwise. How would the compiler know that a call to foo.bar.someFunc belongs to one version or another if both have the same fully qualified name?

Or maybe I'm misunderstanding you (and I'm apparently not the only one in this thread). What problem are you trying to solve? Why do you need different versions of the same module or package at the same time in the same program?