Can someone tell me what are pros and cons of having multiple extra small dub packages that depend on each other versus one dub package that has a bunch of functionality? Good example for this is dlib (https://github.com/gecko0307/dlib). It has many functionalities that could be split into separate packages.

The way I see it the advantage of smaller packages is that users can pick and choose and and only have the code they really need in their project, but the con could become managing a lot of dependencies. Also I am not sure how compile time on clean project and previously compiled project would be affected.

On Monday, 29 October 2018 at 11:31:55 UTC, Igor wrote:
> Can someone tell me what are pros and cons of having multiple extra small dub packages that depend on each other versus one dub package that has a bunch of functionality? Good example for this is dlib (https://github.com/gecko0307/dlib). It has many functionalities that could be split into separate packages.
>
> The way I see it the advantage of smaller packages is that users can pick and choose and and only have the code they really need in their project, but the con could become managing a lot of dependencies. Also I am not sure how compile time on clean project and previously compiled project would be affected.

I'd use subpackages in such cases. This way you can either have one dependency on the whole thing, or select only a few subpackages.

On Monday, 29 October 2018 at 11:31:55 UTC, Igor wrote:
> The way I see it the advantage of smaller packages is that users can pick and choose and and only have the code they really need in their project, but the con could become managing a lot of dependencies. Also I am not sure how compile time on clean project and previously compiled project would be affected.

Pros:
  Users can pick exactly what they need.
  Encourages decoupling instead of too much cohesion.
  Less code to build and maintain.
  Less chances of breakage on upgrade since you depend on less.
  Improve build time since only modified sub-packages get rebuilt.
  Good for the ecosystem.

Cons:
  More link-time operations when not using --combined, each sub-package is compiled at once. Too much sub-package can slow down builds.
  Possibly hitting more DUB edge cases (less the case since DUB has tests)
  Directory layout may need to change for proper VisualD support.
  On the DUB registry, sub-packages are less popular than "big" packages because less discoverable and for some reasons some people won't just pick a sub-package when there is a toplevel package.

On Thursday, 1 November 2018 at 14:07:37 UTC, Guillaume Piolat wrote:
> On Monday, 29 October 2018 at 11:31:55 UTC, Igor wrote:
>> The way I see it the advantage of smaller packages is that users can pick and choose and and only have the code they really need in their project, but the con could become managing a lot of dependencies. Also I am not sure how compile time on clean project and previously compiled project would be affected.
>
> Pros:
>   Users can pick exactly what they need.
>   Encourages decoupling instead of too much cohesion.
>   Less code to build and maintain.
>   Less chances of breakage on upgrade since you depend on less.
>   Improve build time since only modified sub-packages get rebuilt.
>   Good for the ecosystem.
>
> Cons:
>   More link-time operations when not using --combined, each sub-package is compiled at once. Too much sub-package can slow down builds.
>   Possibly hitting more DUB edge cases (less the case since DUB has tests)
>   Directory layout may need to change for proper VisualD support.
>   On the DUB registry, sub-packages are less popular than "big" packages because less discoverable and for some reasons some people won't just pick a sub-package when there is a toplevel package.

Thanks for the list Guillaume.

I don't think subpackages are a good choice for what I have in mind. For example there is a number of packages in repository that offer image loading and saving to multiple formats, but what I am looking for is the most simple PNG reader that just supports the most common formats, no indexed or interlaced, but is extensible and in case I do get to need those I can just add dependency to PngIndexed and PngInterlaced packages and get support for those too. After that I might need to also use PNG writer which would be a separate package. Subpackage in this scenario (and in my mind) would only make sense for some common code that these packages would share.

Of course it could be that I don't fully understand subpackages... What do you think about above scenario? Are there any points you would add or change regarding it specifically?