How to avoid using package.d

[felixfeixu]

Hi,

I'm reading https://dpldocs.info/this-week-in-arsd/Blog.Posted_2023_10_30.html and it says:

DON'T use package.d. It is a poorly designed, buggy mess. (Added Nov 2, 2023)

I would like to know, if a package has sub folders, how to design the package name hierarchy if packages.d is not suggested to use? I would like to read the do together with the dont.

[adamdruppe]

package.d is used for one case and one case only: import toplevel; when toplevel and toplevel.submods both exist.

So the alternative is to just not import toplevel;. Instead, either import the specific things you need from below, or make a differently-named module that public imports (same as package.d but with a different name), like import toplevel.all; or import toplevel_all; depending on where you want it.

[andrey-zherikov]

If I have toplevel.d and toplevel\package.d - which one will be picked up by import toplevel;?

Can I have this setup and will it work correctly?

-  toplevel.d
\- toplevel/
    |- module1.d
    \- module2.d

where toplevel.d publicly includes toplevel.module1 and topleve.module2?

[adamdruppe]

That's part of why I hate the design of package.d: it could be either, depending on kinda random factors. This caused a lot of problems when Phobos first started using package.d and people tried updating their install without deleting all the files first.

So no, that setup will not work. I'd like to make it work, but the compiler implementation has all kinds of weird special cases for the filename "package.d" specifically that is hard to fix.