• Igor (10/10) Oct 29 2018 Can someone tell me what are pros and cons of having multiple
• Laurent =?UTF-8?B?VHLDqWd1aWVy?= (4/14) Oct 29 2018 I'd use subpackages in such cases. This way you can either have
• Guillaume Piolat (19/24) Nov 01 2018 Pros:
• Igor (17/44) Nov 02 2018 Thanks for the list Guillaume.

Igor <stojkovic.igor gmail.com> writes:

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.

Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com> writes:

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.

Guillaume Piolat <spam smam.org> writes:

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.

Igor <stojkovic.igor gmail.com> writes:

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?