On 02.11.23 13:52, BoQsc wrote:
> Well the whole thread is about importing `package.d` while being inside package to provide runnable working example which contains debug information of the package.

Sorry, but I have never seen a package that includes examples within the package directory itself, nor am I able to imagine why anybody would want that. It would just be polluting the package folder with unnecessary files.

Examples are usually distributed in a separate directory, usually at the highest level of the distributable. As for tests, there are `unittest` blocks, and if necessary, they are placed in yet another separate directory.

Anyway, your point is moot, because even if you were able to import `package.d`, it would still fail at:

```
public import waffle.testing1;
public import waffle.testing2;
```

and for exactly the same reason: the compiler would look for `waffle/testing1.d` and it wouldn't find it withing `waffle/`.

You simply can't expect to do `import waffle.foo` from within `waffle/` itself (unless you have another `waffle` folder in it, which is often the case).

You always invoke the compiler from the outside the package structure, that's also how it works in java.

On 02.11.23 14:15, Arafel wrote:
> 
> You simply can't expect to do `import waffle.foo` from within `waffle/` itself (unless you have another `waffle` folder in it, which is often the case).


Sorry, this is wrong. It should read:

You simply can't expect to do `import waffle.foo` **when invoking the compiler** within `waffle/` itself (unless you have another `waffle` folder in it, which is often the case).

You are actually perfectly fine to import other parts of the same package, as long as you run the compiler from right outside the package, or adjust the import paths accordingly.

On Thursday, November 2, 2023 7:04:37 AM MDT Adam D Ruppe via Digitalmars-d- learn wrote:
> On Thursday, 2 November 2023 at 12:52:35 UTC, BoQsc wrote:
> > Therefore the need to import `package.d` is needed and I can't see a solution, which means
>
> tbh package.d should never be used. It is a poorly designed, buggy misfeature of the language with plenty of better working alternatives (it is no different than making a `module yourthing.all;` people can import execpt with more limitations and bugs.)

The entire reason that it was added to the language was to be able to split up existing modules without breaking code. And it does that well. It was never intended to be used for anything else, but of course, some people always find ways to misuse a feature.

package.d is indeed completely unnecessary for creating a module that publicly imports other modules in order to be able to import a single module and get several modules. Either way, personally, I don't think that that's something that should typically be done (with package.d or with any module name), but for whatever reason, some folks seem to love the idea.

- Jonathan M Davis

On Thursday, 2 November 2023 at 19:30:58 UTC, Jonathan M Davis wrote:
> The entire reason that it was added to the language was to be able to split up existing modules without breaking code. And it does that well.

No, it doesn't do that well at all. In fact, it does that so extremely poorly that (as you might recall) there were a very large number of support requests shortly after Phobos started using it about broken builds, since it would keep the old file and the new file when you updated and this stupid, idiotic design can't handle that situation.

This only subsided because enough time has passed that nobody tries using it to break up existing modules anymore.

It is just a *terrible* design that never should have passed review. It is randomly inconsistent with the rest of the language and this manifests as several bugs.

(including but not limited to:

https://issues.dlang.org/show_bug.cgi?id=14687 doesn't work with .di
https://issues.dlang.org/show_bug.cgi?id=17699 breaks if you try to use it for its intended purpose
https://issues.dlang.org/show_bug.cgi?id=20563 error messages hit random problems
<can't find the link> all-at-once vs separate compilation of package leads to inconsistent reflection results

im sure the list went on if i spent a few more minutes looking for my archives)


> package.d is indeed completely unnecessary for creating a module that publicly imports other modules in order to be able to import a single module and get several modules.

Yeah, it is a terrible feature that is poorly designed, hackily implemented, and serves no legitimate use case.

On Thursday, 2 November 2023 at 19:43:01 UTC, Adam D Ruppe wrote:
> On Thursday, 2 November 2023 at 19:30:58 UTC, Jonathan M Davis wrote:
>> The entire reason that it was added to the language was to be able to split up existing modules without breaking code. And it does that well.
>
> No, it doesn't do that well at all. In fact, it does that so extremely poorly that (as you might recall) there were a very large number of support requests shortly after Phobos started using it about broken builds, since it would keep the old file and the new file when you updated and this stupid, idiotic design can't handle that situation.
>
> This only subsided because enough time has passed that nobody tries using it to break up existing modules anymore.
>
> It is just a *terrible* design that never should have passed review. It is randomly inconsistent with the rest of the language and this manifests as several bugs.
>
> (including but not limited to:
>
> https://issues.dlang.org/show_bug.cgi?id=14687 doesn't work with .di
> https://issues.dlang.org/show_bug.cgi?id=17699 breaks if you try to use it for its intended purpose
> https://issues.dlang.org/show_bug.cgi?id=20563 error messages hit random problems
> <can't find the link> all-at-once vs separate compilation of package leads to inconsistent reflection results
>
> im sure the list went on if i spent a few more minutes looking for my archives)
>
>
>> package.d is indeed completely unnecessary for creating a module that publicly imports other modules in order to be able to import a single module and get several modules.
>
> Yeah, it is a terrible feature that is poorly designed, hackily implemented, and serves no legitimate use case.

Is there any guide how one can refactor single-module package into multi-module package with distinction between public and private modules?

On Fri, Nov 03, 2023 at 12:19:48AM +0000, Andrey Zherikov via Digitalmars-d-learn wrote:
> On Thursday, 2 November 2023 at 19:43:01 UTC, Adam D Ruppe wrote:
> > On Thursday, 2 November 2023 at 19:30:58 UTC, Jonathan M Davis wrote:
> > > The entire reason that it was added to the language was to be able to split up existing modules without breaking code. And it does that well.
> > 
> > No, it doesn't do that well at all. In fact, it does that so extremely poorly that (as you might recall) there were a very large number of support requests shortly after Phobos started using it about broken builds, since it would keep the old file and the new file when you updated and this stupid, idiotic design can't handle that situation.
> > 
> > This only subsided because enough time has passed that nobody tries using it to break up existing modules anymore.
> > 
> > It is just a *terrible* design that never should have passed review. It is randomly inconsistent with the rest of the language and this manifests as several bugs.
> > 
> > (including but not limited to:
> > 
> > https://issues.dlang.org/show_bug.cgi?id=14687 doesn't work with .di
> > https://issues.dlang.org/show_bug.cgi?id=17699 breaks if you try to use
> > it for its intended purpose
> > https://issues.dlang.org/show_bug.cgi?id=20563 error messages hit random
> > problems
> > <can't find the link> all-at-once vs separate compilation of package
> > leads to inconsistent reflection results
> > 
> > im sure the list went on if i spent a few more minutes looking for my archives)
> > 
> > 
> > > package.d is indeed completely unnecessary for creating a module that publicly imports other modules in order to be able to import a single module and get several modules.
> > 
> > Yeah, it is a terrible feature that is poorly designed, hackily implemented, and serves no legitimate use case.
> 
> Is there any guide how one can refactor single-module package into multi-module package with distinction between public and private modules?

Supposedly you can do this:

	/* Original: */

	// pkg/mymodule.d
	module mymodule;
	... // code here

	// main.d
	import mymodule;
	void main() { ... }

	/* Split */

	// pkg/mymodule/pub_submod.d
	module mymodule.pub_submod;
	... // code here

	// pkg/mymodule/priv_submod.d
	module mymodule.priv_submod;
	... // code here

	// pkg/mymodule/package.d
	module mymodule;
	public import priv_submod;

	// main.d
	import mymodule;
	void main() { ... }

Barring the issues listed above, of course.


T

-- 
"The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."

On Friday, 3 November 2023 at 00:52:18 UTC, H. S. Teoh wrote:
> Supposedly you can do this:
>
> 	/* Original: */
>
> 	// pkg/mymodule.d
> 	module mymodule;
> 	... // code here
>
> 	// main.d
> 	import mymodule;
> 	void main() { ... }
>
> 	/* Split */
>
> 	// pkg/mymodule/pub_submod.d
> 	module mymodule.pub_submod;
> 	... // code here
>
> 	// pkg/mymodule/priv_submod.d
> 	module mymodule.priv_submod;
> 	... // code here
>
> 	// pkg/mymodule/package.d
> 	module mymodule;
> 	public import priv_submod;
>
> 	// main.d
> 	import mymodule;
> 	void main() { ... }
>
> Barring the issues listed above, of course.

I know how to do this with package.d but my question was about "package.d is bad design decision" - How would I do this refactoring without dedicated "main package file"?
Python, for example, has __init__.py as well

On Friday, 3 November 2023 at 00:19:48 UTC, Andrey Zherikov wrote:
> Is there any guide how one can refactor single-module package into multi-module package with distinction between public and private modules?

Call the modules literally anything else and it works better.

So say you have module foo.bar. You could keep that and put your multiple modules in a different thing like foo.bar_parts.part and foo.bar_parts.part2. This maintains compatibility on the user side; if they were previously using foo.bar, things keep working for them.

Or, you could keep everything under foo.bar, but add a foo.bar.all that provides the old api. Users would have to adjust their imports to say `import foo.bar.all;` instead. This has more potential for transition breakage, but it keeps the new modules under the old namespace.

I recommend option 1: having the new foo.bar_parts where the implementation actually goes. (Or you could call it whatever you want.) This avoids the whole package.d thing while still letting you and your user arrange modules how you like.

You might also have a thing like `foo.bar_implementation` which is not intended for public use.