• JS (5/5) Jul 17 2013 Is is possible to import all modules using something import
• JS (11/16) Jul 17 2013 To be clear, I'd basically like to have one interface/class per
• JS (3/20) Jul 17 2013 I imagine a string mixin could be used if necessary but I'm
• monarch_dodra (17/22) Jul 17 2013 I *think* that if you use a boost like scheme, you can do it. I'd
• JS (8/31) Jul 17 2013 so you are saying that by using public import it will make all
• monarch_dodra (24/60) Jul 17 2013 Yes, that should be it. Note, however, that a simple "public
• Jesse Phillips (9/22) Jul 17 2013 Public import adds the symbols to the module and makes them
• Jonathan M Davis (4/10) Jul 17 2013 This has been implemented in git master:
• JS (29/39) Jul 17 2013 Thanks, I've updated the compiler to 2.063.2 and made my
• Jonathan M Davis (24/78) Jul 18 2013 Normally, nothing like that has any business in sc.ini. sc.ini is suppos...
• JS (17/113) Jul 18 2013 I intentionally chose uppercase because it is more informative. I
• Jonathan M Davis (9/13) Jul 18 2013 The base directory of each package hierarchy must be passed to dmd with ...
• JS (31/51) Jul 18 2013 using All instead of package as the name worked really well, I
• Jonathan M Davis (14/17) Jul 18 2013 Yes. You can do that, though again I'd point out that using uppercase le...
• JS (11/38) Jul 18 2013 Yes, but it's obviously not useable at this point and when it
• Jonathan M Davis (5/8) Jul 18 2013 Do you mean the package attribute or package.d? package.d should work ju...
• JS (4/15) Jul 18 2013 When I used package.d things didn't work out like they do using
• Jonathan M Davis (12/30) Jul 18 2013 Well, what you were posting was wrong, and I believe that I pointed out ...
• JS (25/62) Jul 18 2013 Yes, that is one of the things I tried.. and I'm not working from
• Jonathan M Davis (4/8) Jul 18 2013 As I think that I said earlier (though maybe I forgot to), you have to h...
• JS (6/17) Jul 19 2013 Ok, that explains it. I thought getting 2.063.2 would be good
• JS (8/8) Jul 18 2013 One of the reasons I used Package.d was so I can get around an

"JS" <js.mdnq gmail.com> writes:

Is is possible to import all modules using something import 
a.b.*;?

I'd like to partition some modules up into smaller pieces to 
simplify modification(reduce scrolling) but, of course, this 
increases the number of imports drastically.

"JS" <js.mdnq gmail.com> writes:

On Wednesday, 17 July 2013 at 09:34:58 UTC, JS wrote:
 Is is possible to import all modules using something import 
 a.b.*;?

 I'd like to partition some modules up into smaller pieces to 
 simplify modification(reduce scrolling) but, of course, this 
 increases the number of imports drastically.


To be clear, I'd basically like to have one interface/class per 
file but a directory/folder is a sort of combined module as far 
as imports go.


e.g.,

/dir/a.d
/dir/b.d
/dir/c.d

could import a,b,c by using import dir or import dir.* instead of 
import a, b, c

each module has the same name as it's file.

"JS" <js.mdnq gmail.com> writes:

On Wednesday, 17 July 2013 at 09:54:28 UTC, JS wrote:
 On Wednesday, 17 July 2013 at 09:34:58 UTC, JS wrote:
 Is is possible to import all modules using something import 
 a.b.*;?

 I'd like to partition some modules up into smaller pieces to 
 simplify modification(reduce scrolling) but, of course, this 
 increases the number of imports drastically.


 To be clear, I'd basically like to have one interface/class per 
 file but a directory/folder is a sort of combined module as far 
 as imports go.


 e.g.,

 /dir/a.d
 /dir/b.d
 /dir/c.d

 could import a,b,c by using import dir or import dir.* instead 
 of import a, b, c

 each module has the same name as it's file.

I imagine a string mixin could be used if necessary but I'm 
hoping there is a better way.

"monarch_dodra" <monarchdodra gmail.com> writes:

On Wednesday, 17 July 2013 at 09:34:58 UTC, JS wrote:
 Is is possible to import all modules using something import 
 a.b.*;?

 I'd like to partition some modules up into smaller pieces to 
 simplify modification(reduce scrolling) but, of course, this 
 increases the number of imports drastically.

I *think* that if you use a boost like scheme, you can do it. I'd 
look like this:

+
+ a.d
+ a //Dir
+-+ b.d
   + c.d

Where a.d contains:
//----
public import a.b, a.c;
//----

It requries a bit of maintenance though.
It work for me, although I think there are open bugs about this 
in regards to conflicting modules/packages.

For example, testing this, it works with dmd, but it fails for me 
with rdmd...

"JS" <js.mdnq gmail.com> writes:

On Wednesday, 17 July 2013 at 09:57:04 UTC, monarch_dodra wrote:
 On Wednesday, 17 July 2013 at 09:34:58 UTC, JS wrote:
 Is is possible to import all modules using something import 
 a.b.*;?

 I'd like to partition some modules up into smaller pieces to 
 simplify modification(reduce scrolling) but, of course, this 
 increases the number of imports drastically.

 I *think* that if you use a boost like scheme, you can do it. 
 I'd look like this:

 +
 + a.d
 + a //Dir
 +-+ b.d
   + c.d

 Where a.d contains:
 //----
 public import a.b, a.c;
 //----

 It requries a bit of maintenance though.
 It work for me, although I think there are open bugs about this 
 in regards to conflicting modules/packages.

 For example, testing this, it works with dmd, but it fails for 
 me with rdmd...

so you are saying that by using public import it will make all 
imports of imports available?

e.g.,

a.d
public import a.b, a.c;

test.d
import a; // will also import a.b and a.c?

"monarch_dodra" <monarchdodra gmail.com> writes:

On Wednesday, 17 July 2013 at 10:04:53 UTC, JS wrote:
 On Wednesday, 17 July 2013 at 09:57:04 UTC, monarch_dodra wrote:
 On Wednesday, 17 July 2013 at 09:34:58 UTC, JS wrote:
 Is is possible to import all modules using something import 
 a.b.*;?

 I'd like to partition some modules up into smaller pieces to 
 simplify modification(reduce scrolling) but, of course, this 
 increases the number of imports drastically.

 I *think* that if you use a boost like scheme, you can do it. 
 I'd look like this:

 +
 + a.d
 + a //Dir
 +-+ b.d
  + c.d

 Where a.d contains:
 //----
 public import a.b, a.c;
 //----

 It requries a bit of maintenance though.
 It work for me, although I think there are open bugs about 
 this in regards to conflicting modules/packages.

 For example, testing this, it works with dmd, but it fails for 
 me with rdmd...

 so you are saying that by using public import it will make all 
 imports of imports available?

 e.g.,

 a.d
 public import a.b, a.c;

 test.d
 import a; // will also import a.b and a.c?

Yes, that should be it. Note, however, that a simple "public 
import" will *also* import the imported "module" as if it was 
inside, eg:

//===============================
//a.b.d:
module a.b;
void foo();

//a.c.d:
module a.c;
void bar();

//main.d
import a;
void main()
{
     foo(); //OK
     bar(); //OK
     a.foo(); //OK (!!!)
     a.bar(); //OK (!!!)
     a.b.foo(); //OK
     a.c.bar(); //OK
}
//===============================

To be frank, I don't know if this is a bug, or a feature...

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

On Wednesday, 17 July 2013 at 11:45:09 UTC, monarch_dodra wrote:
 //main.d
 import a;
 void main()
 {
     foo(); //OK
     bar(); //OK
     a.foo(); //OK (!!!)
     a.bar(); //OK (!!!)
     a.b.foo(); //OK
     a.c.bar(); //OK
 }
 //===============================

 To be frank, I don't know if this is a bug, or a feature...

Public import adds the symbols to the module and makes them 
public, by default they are private.

     foo();
     a.foo();

These are equivalent since a contains the symbols of b. This is 
has the annoyance:

     import a, b;

     foo() // Ambiguous a.foo and b.foo()

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Wednesday, July 17, 2013 11:34:56 JS wrote:
 Is is possible to import all modules using something import
 a.b.*;?
 
 I'd like to partition some modules up into smaller pieces to
 simplify modification(reduce scrolling) but, of course, this
 increases the number of imports drastically.

This has been implemented in git master:

http://wiki.dlang.org/DIP37

- Jonathan M Davis

"JS" <js.mdnq gmail.com> writes:

On Wednesday, 17 July 2013 at 17:51:15 UTC, Jonathan M Davis 
wrote:
 On Wednesday, July 17, 2013 11:34:56 JS wrote:
 Is is possible to import all modules using something import
 a.b.*;?
 
 I'd like to partition some modules up into smaller pieces to
 simplify modification(reduce scrolling) but, of course, this
 increases the number of imports drastically.

 This has been implemented in git master:

 http://wiki.dlang.org/DIP37

 - Jonathan M Davis

Thanks, I've updated the compiler to 2.063.2 and made my 
hierarchy like

lib/package.d
lib/mod.d
lib/dir1/package.d
lib/dir1/a.d
lib/dir1/b.d
lib/dir2/package.d
lib/dir2/c.d

each package.d file publically imports all sub packages(by 
chaining package imports and importing same directory modules):

lib/package.d:
module Package;
public import mod.d;
public import dir1.Package;
public import dir2.Package;

lib/dir1/package.d;
module dir1.Package;
public import dir1.a;
public import dir2.b;


etc....

This should allow me to import any resolution I need. e.g., if I 
want the whole library I just import lib/package.d.


When I do this dmd can't find my module files.

I have only included the root dir(lib) in sc.ini, hopefully I do 
not need to include every single subdirectory in lib for it to 
work ;/ ? (this would be better to be auto generated)

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Thursday, July 18, 2013 08:45:25 JS wrote:
 On Wednesday, 17 July 2013 at 17:51:15 UTC, Jonathan M Davis
 
 wrote:
 On Wednesday, July 17, 2013 11:34:56 JS wrote:
 Is is possible to import all modules using something import
 a.b.*;?
 
 I'd like to partition some modules up into smaller pieces to
 simplify modification(reduce scrolling) but, of course, this
 increases the number of imports drastically.

 
 This has been implemented in git master:
 
 http://wiki.dlang.org/DIP37
 
 - Jonathan M Davis

 
 Thanks, I've updated the compiler to 2.063.2 and made my
 hierarchy like
 
 lib/package.d
 lib/mod.d
 lib/dir1/package.d
 lib/dir1/a.d
 lib/dir1/b.d
 lib/dir2/package.d
 lib/dir2/c.d
 
 each package.d file publically imports all sub packages(by
 chaining package imports and importing same directory modules):
 
 lib/package.d:
 module Package;
 public import mod.d;
 public import dir1.Package;
 public import dir2.Package;
 
 lib/dir1/package.d;
 module dir1.Package;
 public import dir1.a;
 public import dir2.b;
 
 
 etc....
 
 This should allow me to import any resolution I need. e.g., if I
 want the whole library I just import lib/package.d.
 
 
 When I do this dmd can't find my module files.
 
 I have only included the root dir(lib) in sc.ini, hopefully I do
 not need to include every single subdirectory in lib for it to
 work ;/ ? (this would be better to be auto generated)

Normally, nothing like that has any business in sc.ini. sc.ini is supposed to 
be for the standard stuff, not your personal stuff. You should be passing it to 
the compiler using the appropriate compiler flags (-I in this case IIRC). Now, 
you obviously _can_ stick it all in your sc.ini file you want to, but I believe 
that that would generally be considered bad practice.

As for your actual files, you're making several mistakes.

1. It's not module Package. Not only is it generally considered bad practice 
to use any uppercase letters in a module or package name, but the module name 
for a package.d file does not include package. So, for instance, if 
std.datetime were a package with std/datetime/package.d in it, then that 
package.d file would have module std.datetime; at the top.

2. Maybe it's just a typo, but you have some imports which end with .d, which 
isn't legal.

3. A top-level package.d won't work. There's no name to give it to import and 
no name to give its module declaration. Also, I don't believe that the top 
level is considered a package in the first place. I believe that the only 
reason the package modifer works on the top level is the fact that package is 
outright broken right now ( http://d.puremagic.com/issues/show_bug.cgi?id=143 
) and is pretty much treated as public. Once that's been fixed, any attempt at 
using package at the top level will fail.

I might be missing something else, but I think that your main problem is how 
you name the module declarations in your package.d files.

- Jonathan M Davis

"JS" <js.mdnq gmail.com> writes:

On Thursday, 18 July 2013 at 07:16:35 UTC, Jonathan M Davis wrote:
 On Thursday, July 18, 2013 08:45:25 JS wrote:
 On Wednesday, 17 July 2013 at 17:51:15 UTC, Jonathan M Davis
 
 wrote:
 On Wednesday, July 17, 2013 11:34:56 JS wrote:
 Is is possible to import all modules using something import
 a.b.*;?
 
 I'd like to partition some modules up into smaller pieces to
 simplify modification(reduce scrolling) but, of course, this
 increases the number of imports drastically.

 
 This has been implemented in git master:
 
 http://wiki.dlang.org/DIP37
 
 - Jonathan M Davis

 
 Thanks, I've updated the compiler to 2.063.2 and made my
 hierarchy like
 
 lib/package.d
 lib/mod.d
 lib/dir1/package.d
 lib/dir1/a.d
 lib/dir1/b.d
 lib/dir2/package.d
 lib/dir2/c.d
 
 each package.d file publically imports all sub packages(by
 chaining package imports and importing same directory modules):
 
 lib/package.d:
 module Package;
 public import mod.d;
 public import dir1.Package;
 public import dir2.Package;
 
 lib/dir1/package.d;
 module dir1.Package;
 public import dir1.a;
 public import dir2.b;
 
 
 etc....
 
 This should allow me to import any resolution I need. e.g., if 
 I
 want the whole library I just import lib/package.d.
 
 
 When I do this dmd can't find my module files.
 
 I have only included the root dir(lib) in sc.ini, hopefully I 
 do
 not need to include every single subdirectory in lib for it to
 work ;/ ? (this would be better to be auto generated)

 Normally, nothing like that has any business in sc.ini. sc.ini 
 is supposed to
 be for the standard stuff, not your personal stuff. You should 
 be passing it to
 the compiler using the appropriate compiler flags (-I in this 
 case IIRC). Now,
 you obviously _can_ stick it all in your sc.ini file you want 
 to, but I believe
 that that would generally be considered bad practice.

 As for your actual files, you're making several mistakes.

 1. It's not module Package. Not only is it generally considered 
 bad practice
 to use any uppercase letters in a module or package name, but 
 the module name
 for a package.d file does not include package. So, for 
 instance, if
 std.datetime were a package with std/datetime/package.d in it, 
 then that
 package.d file would have module std.datetime; at the top.

I intentionally chose uppercase because it is more informative. I 
am not worried about cross-compilation issues at this point. 
iPackage.d looks nicer than ipackage.d.

I did add Package to the end of module names and did uppercase 
package.d, possibly that is part of thep roblem.

 2. Maybe it's just a typo, but you have some imports which end 
 with .d, which
 isn't legal.

yes

 3. A top-level package.d won't work. There's no name to give it 
 to import and
 no name to give its module declaration. Also, I don't believe 
 that the top
 level is considered a package in the first place. I believe 
 that the only
 reason the package modifer works on the top level is the fact 
 that package is
 outright broken right now ( 
 http://d.puremagic.com/issues/show_bug.cgi?id=143
 ) and is pretty much treated as public. Once that's been fixed, 
 any attempt at
 using package at the top level will fail.

 I might be missing something else, but I think that your main 
 problem is how
 you name the module declarations in your package.d files.

 - Jonathan M Davis

I'll probably have to setup visual d to insert the includes dirs 
on the command line. I had the same issue before when trying to 
include modules and edited sc.ini to get it to work. As far as I 
can tell, there is no way to set global includes in visual d 
which is why I used sc.ini. (I don't want to setup the includes 
directory for each project I create)

In any case, the real question I have is: Does dmd require each 
directory for each module to be included by -I? Or is the base 
directory good enough and package resolution will get at the sub 
directories?

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Thursday, July 18, 2013 09:25:46 JS wrote:
 In any case, the real question I have is: Does dmd require each
 directory for each module to be included by -I? Or is the base
 directory good enough and package resolution will get at the sub
 directories?

The base directory of each package hierarchy must be passed to dmd with -I. 
So, if you have the module abc.foo.bar, then dmd must have been passed the 
directory that abc is in. A module's fully qualified name is its directory 
hierarchy, and dmd is always looking for the base of the hierarchy, so you 
give it each directory which is the root of a package hierarchy. If you have 
abc.foo.bar, and you passed it the abc or abc/foo, it would then effectively be 
looking for abc/abc/foo/bar.d or abc/foo/abc/foo/bar.d.

- Jonathan M Davis

"JS" <js.mdnq gmail.com> writes:

On Thursday, 18 July 2013 at 07:43:33 UTC, Jonathan M Davis wrote:
 On Thursday, July 18, 2013 09:25:46 JS wrote:
 In any case, the real question I have is: Does dmd require each
 directory for each module to be included by -I? Or is the base
 directory good enough and package resolution will get at the 
 sub
 directories?

 The base directory of each package hierarchy must be passed to 
 dmd with -I.
 So, if you have the module abc.foo.bar, then dmd must have been 
 passed the
 directory that abc is in. A module's fully qualified name is 
 its directory
 hierarchy, and dmd is always looking for the base of the 
 hierarchy, so you
 give it each directory which is the root of a package 
 hierarchy. If you have
 abc.foo.bar, and you passed it the abc or abc/foo, it would 
 then effectively be
 looking for abc/abc/foo/bar.d or abc/foo/abc/foo/bar.d.

 - Jonathan M Davis


using All instead of package as the name worked really well, I 
can easily chain imports and each module can import the root to 
import the whole library.

e.g.,
lib/All.d
lib/modules*.d
lib/dir?/.../dir?/modules*.d

each module only has to import All to get access to the whole 
library. Only the final directories need to import each module. 
Each internal directory just has to import the All.d's of each 
subdirectory and any modules in the same directory.

Seems to work really well and very simple to update and include 
various parts of the library.

e.g.,
/all.d
/a.d
/dir/all.d
/dir/b.d

all.d:
module all;
public import a;
public import dir.b;

/dir/all.d
module dir.all;
public import dir.b;

(I do have my lib partitions for different libraries I have 
something like import mylib.all)

essentially all acts like *. e.g., import dir.*; is the same as 
import dir.all; (except * would automatically import everything 
for you making life easier).

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Thursday, July 18, 2013 10:10:13 JS wrote:
 using All instead of package as the name worked really well, I
 can easily chain imports and each module can import the root to
 import the whole library.

Yes. You can do that, though again I'd point out that using uppercase letters 
in module and package names is generally frowned upon. That's just how public 
import works, and plenty of folks have had all.d files in their projects for 
years now. None of that requires a new version of dmd. The key thing about the 
DIP (which _does_ require_ the git version of dmd) is that it allows you to 
import the package as if it were a module. This will allow us to do things 
like split up std.datetime or std.algorithm in place without breaking anyone's 
code, as import std.datetime or import std.algorithm would continue to work as 
they had as long as their package.d files publicly imported everything that had 
been in those modules before.

I would expect that in the long term, package.d will supplant all.d 
completely, but you're obviously free to use it all.d if you want to.

- Jonathan M Davis

"JS" <js.mdnq gmail.com> writes:

On Thursday, 18 July 2013 at 08:50:34 UTC, Jonathan M Davis wrote:
 On Thursday, July 18, 2013 10:10:13 JS wrote:
 using All instead of package as the name worked really well, I
 can easily chain imports and each module can import the root to
 import the whole library.

 Yes. You can do that, though again I'd point out that using 
 uppercase letters
 in module and package names is generally frowned upon. That's 
 just how public
 import works, and plenty of folks have had all.d files in their 
 projects for
 years now. None of that requires a new version of dmd. The key 
 thing about the
 DIP (which _does_ require_ the git version of dmd) is that it 
 allows you to
 import the package as if it were a module. This will allow us 
 to do things
 like split up std.datetime or std.algorithm in place without 
 breaking anyone's
 code, as import std.datetime or import std.algorithm would 
 continue to work as
 they had as long as their package.d files publicly imported 
 everything that had
 been in those modules before.

 I would expect that in the long term, package.d will supplant 
 all.d
 completely, but you're obviously free to use it all.d if you 
 want to.

Yes, but it's obviously not useable at this point and when it 
does it will be easy to switch over to.

AFAIK, the only issue with uppercase is case sensitivity, and as 
long as d does not modify case then I'm not worried about it. 
Just because something is frowned apon doesn't mean squat to me 
unless there is a good reason. I'll prefer readability over 
common useage.

Essentially all emulates the package.d, and I like it because 
it's descriptive and easily maintainable... thats all I was after 
in the first place. Too bad package doesn't work properly ;/

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Thursday, July 18, 2013 11:38:41 JS wrote:
 Essentially all emulates the package.d, and I like it because
 it's descriptive and easily maintainable... thats all I was after
 in the first place. Too bad package doesn't work properly ;/

Do you mean the package attribute or package.d? package.d should work just 
fine. I'm not aware of any outstanding bugs with it. The attribute is still 
broken though, I believe.

- Jonathan M Davis

"JS" <js.mdnq gmail.com> writes:

On Thursday, 18 July 2013 at 19:35:15 UTC, Jonathan M Davis wrote:
 On Thursday, July 18, 2013 11:38:41 JS wrote:
 Essentially all emulates the package.d, and I like it because
 it's descriptive and easily maintainable... thats all I was 
 after
 in the first place. Too bad package doesn't work properly ;/

 Do you mean the package attribute or package.d? package.d 
 should work just
 fine. I'm not aware of any outstanding bugs with it. The 
 attribute is still
 broken though, I believe.

 - Jonathan M Davis

When I used package.d things didn't work out like they do using 
all. It may be due to bugs on my end(I had a few typos). Maybe I 
will try it again though(simple rename and remove .all).

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Thursday, July 18, 2013 23:53:53 JS wrote:
 On Thursday, 18 July 2013 at 19:35:15 UTC, Jonathan M Davis wrote:
 On Thursday, July 18, 2013 11:38:41 JS wrote:
 Essentially all emulates the package.d, and I like it because
 it's descriptive and easily maintainable... thats all I was
 after
 in the first place. Too bad package doesn't work properly ;/

 
 Do you mean the package attribute or package.d? package.d
 should work just
 fine. I'm not aware of any outstanding bugs with it. The
 attribute is still
 broken though, I believe.
 
 - Jonathan M Davis

 
 When I used package.d things didn't work out like they do using
 all. It may be due to bugs on my end(I had a few typos). Maybe I
 will try it again though(simple rename and remove .all).

Well, what you were posting was wrong, and I believe that I pointed out why. A 
package.d file's module declaration needs to have the same name as the package. 
So, if you have

abc/foo/package.d

then package.d needs

module abc.foo;

for its module declaration. Then you import the package as if it were a 
module, so you get any public imports which were in it. But as I said before, 
this won't work for the top level, because the top level isn't a package. You 
need a sub-folder to have a package.

- Jonathan m Davis

"JS" <js.mdnq gmail.com> writes:

On Thursday, 18 July 2013 at 23:14:39 UTC, Jonathan M Davis wrote:
 On Thursday, July 18, 2013 23:53:53 JS wrote:
 On Thursday, 18 July 2013 at 19:35:15 UTC, Jonathan M Davis 
 wrote:
 On Thursday, July 18, 2013 11:38:41 JS wrote:
 Essentially all emulates the package.d, and I like it 
 because
 it's descriptive and easily maintainable... thats all I was
 after
 in the first place. Too bad package doesn't work properly ;/

 
 Do you mean the package attribute or package.d? package.d
 should work just
 fine. I'm not aware of any outstanding bugs with it. The
 attribute is still
 broken though, I believe.
 
 - Jonathan M Davis

 
 When I used package.d things didn't work out like they do using
 all. It may be due to bugs on my end(I had a few typos). Maybe 
 I
 will try it again though(simple rename and remove .all).

 Well, what you were posting was wrong, and I believe that I 
 pointed out why. A
 package.d file's module declaration needs to have the same name 
 as the package.
 So, if you have

 abc/foo/package.d

 then package.d needs

 module abc.foo;

 for its module declaration. Then you import the package as if 
 it were a
 module, so you get any public imports which were in it. But as 
 I said before,
 this won't work for the top level, because the top level isn't 
 a package. You
 need a sub-folder to have a package.

Yes, that is one of the things I tried.. and I'm not working from 
the top level since that is the library container folder which 
contains all the actual libraries which then contain the packages.

When I rename the all.d files to package and import the package I 
get two errors:

Error	1	Error: can only import from a module, not from package JS
Error	2	Error: module JS is in file 'JS.d' which cannot be read		


My hierarchy is

/lib/JS/package.d
module JS;
public import ....

and I import JS by using import JS;

vs using all.d

/lib/JS/All.d
module JS.All;
public import ....

and I import JS by using import JS.All;

otherwise everything is identical. .All works without issue.

Note I reverted to 2.062 because 2.063.2 was causing weird errors 
in Visual D... so this might be the problem but I remember 
getting the same errors when I was trying 2.063.2(but possibly 
not)...

In any case, I'll just stick with All for now, I think I like how 
explicit it is.

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Friday, July 19, 2013 01:25:54 JS wrote:
 Note I reverted to 2.062 because 2.063.2 was causing weird errors
 in Visual D... so this might be the problem but I remember
 getting the same errors when I was trying 2.063.2(but possibly
 not)...

As I think that I said earlier (though maybe I forgot to), you have to have 
git master to use package.d. The feature hasn't been released yet.

- Jonathan M Davis

"JS" <js.mdnq gmail.com> writes:

On Friday, 19 July 2013 at 00:39:03 UTC, Jonathan M Davis wrote:
 On Friday, July 19, 2013 01:25:54 JS wrote:
 Note I reverted to 2.062 because 2.063.2 was causing weird 
 errors
 in Visual D... so this might be the problem but I remember
 getting the same errors when I was trying 2.063.2(but possibly
 not)...

 As I think that I said earlier (though maybe I forgot to), you 
 have to have
 git master to use package.d. The feature hasn't been released 
 yet.

 - Jonathan M Davis

Ok, that explains it. I thought getting 2.063.2 would be good 
enough. I didn't want to have to compile anything so didn't 
bother looking at github.

It would be nice if there was always a latest compiled version of 
master for download(or at least a nightly or weekly build)?

"JS" <js.mdnq gmail.com> writes:

One of the reasons I used Package.d was so I can get around an 
issue like 
https://github.com/D-Programming-Language/dmd/pull/2152 which I 
think I was running into.

Instead I think by renaming Package.d to All.d and import 
dir.All; seems to work ok. Obviously adding .All to everything is 
annoying but it won't be hard to write a parser to fix that once 
package gets working.