www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Small or big dub packages

reply 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.
Oct 29 2018
next sibling parent 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.
Oct 29 2018
prev sibling parent reply 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.
Nov 01 2018
parent 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?
Nov 02 2018