On 9/12/22 09:34, rikki cattermole wrote:

> dub.json
> errornogc/alid/errornogc.d
> circularblocks/alid/circularblocks.d

Considering I may want to let the users import the entire package as well with

  import alid;

how can I achieve my goal of subpackages? Telling me to forget about subpackages altogether :) is an option because I've already spent hours trying to find my way through different directory structures, random dub.json edits, experimenting with ways of stopping dub from fetching and using the bad version of the repo repeatedly, and many other random things...

The main problem is likely I don't have an accurate mental model of the whole thing. For example, I don't know whether dub will take the state of my local directory as-is or will it copy from the committed state of the local repo? I ask because the add-local command puts a commit hash as well. If that's the case, I wouldn't want to commit every little change before seeing it's effect.

Yes, I did the path override thing as well...

Ali

On Wednesday, 14 September 2022 at 08:44:48 UTC, Ali Çehreli wrote:
> Considering I may want to let the users import the entire package as well with

dub is poorly designed and doesn't cooperate well with D features. There's no good solution - hence the hundreds of lines long dub.json trying to hack it in. Like you could have the top-level package depend on all of its own subpackages and then if you depend on it, you can import alid. Lots of spam for something that just works out of the box with stock dmd!

On 14/09/2022 8:44 PM, Ali Çehreli wrote:
> On 9/12/22 09:34, rikki cattermole wrote:
> 
>  > dub.json
>  > errornogc/alid/errornogc.d
>  > circularblocks/alid/circularblocks.d
> 
> Considering I may want to let the users import the entire package as well with
> 
>    import alid;
> 
> how can I achieve my goal of subpackages? Telling me to forget about subpackages altogether :) is an option because I've already spent hours trying to find my way through different directory structures, random dub.json edits, experimenting with ways of stopping dub from fetching and using the bad version of the repo repeatedly, and many other random things...

In your root package you can still have the package.d file.

You would use the version added by Dub to detect if you should public import the other modules.

> DUB provides version identifier of dependencies for conditional compilation with version conditions. Have_<dependency> version identifier can be used for conditional compilation.

https://dub.pm/advanced_usage

On 9/12/22 02:15, Ali Çehreli wrote:
> I am happy to publish on code.dlang.org for the first time:
>
>    https://code.dlang.org/packages/alid

I've fixed 2 of the 3 issues reported here:

  - Removed gratuitous function attributes

  - Fixed Salih's .cycle use case

  - Subpackage design (thinking about it...)

Let's continue with the issues at a more appropriate place:

  https://github.com/acehreli/alid/issues

Thanks! :)

Ali

On 9/14/22 12:08, Ali Çehreli wrote:

>    - Subpackage design (thinking about it...)

Ok, I think I fixed that one as well.

I think my main problem was trying to import 'alid':

  import alid;      // WRONG - Could not make it work
  import alid.alid; // Worked with package.d file

I think subpackages work as well:

  import alid.cached;
  // etc.

(Yes, I used many "I think"s. :) )

Ali

On Thursday, 15 September 2022 at 02:30:43 UTC, Ali Çehreli wrote:
> On 9/14/22 12:08, Ali Çehreli wrote:
>   import alid;      // WRONG - Could not make it work
>   import alid.alid; // Worked with package.d file

What's objection with combining all the code in the package into one module?

SDB@79

On 9/15/22 02:18, Salih Dincer wrote:
> On Thursday, 15 September 2022 at 02:30:43 UTC, Ali Çehreli wrote:
>> On 9/14/22 12:08, Ali Çehreli wrote:
>>   import alid;      // WRONG - Could not make it work
>>   import alid.alid; // Worked with package.d file
> 
> What's objection with combining all the code in the package into one module?
> 
> SDB@79

As a general principal, we don't want to include more than necessary. One reason can be compilation speed and binary size: 'import std;' compiles slow and (likely) adds and initializes module variable my program does not need.

Ali