# Code Redistribution

**URL:** <https://www.ruby-forum.com/t/code-redistribution/103944>\
**Category:** Ruby\
**Created:** [May 11, 2007, 9:03pm UTC](https://www.ruby-forum.com/t/code-redistribution/103944 "2007-05-11T21:03:16Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\
**Post date:** [May 11, 2007, 9:03pm UTC](https://www.ruby-forum.com/t/code-redistribution/103944/1 "2007-05-11T21:03:16Z")

</div>

On my further considerations of code redistribution (from my  
perspective of Facets)…

I think one of the fundamental distinctions that I’ve been missing is  
that which lies between a common utility and a more specialized tool.  
For example, the Command base class is more specialized, while the  
ANSICode module is more a common utility. Ultimately I think it would  
be nice to create a more cohesive tool that covers the full- spectrum  
of requirements for console based apps. While it would make sense to  
include all the components needed for this in the single package,  
eg.“Comrade”, this would discourage others from using those parts for  
their own equivalent utilities. In other words, by including ANSICode  
in “Comrade”, I’ve discouraged others from creating there own command-  
line solutions that could re-utilize ANSICode. For this reason, one  
can argue that something like ANSICode would be better off as it’s own  
package.

However packaging systems are generally poorly suited to small  
reusable libs like this, which typically having but a single file. For  
example, RubyGems package format and conventions for project layouts  
are bulky relative to this need, and it is inefficient in it’s effects  
on Ruby’s loadpath system. Also, it may be foolish to think an  
ANSICode library would get much independent use anyway. If someone  
needed it for another application they’d might just copy and paste it  
into their own project --avoiding the dependency. That’s the other  
issue here. With so many small libraries one could easily have dozens  
of such dependencies per application. While that upholds the common  
mantra of “code reuse”, it also comes at the practical costs of  
dependency. This is the primary reason I came up with the idea of  
GemBundles.

So I suppose I have to ask, what is the goal? Is it to create  
comprehensive solutions such as Comrade? Or simply to offer  
essentially independent reusable components such as ANSICode? And if  
the later, is it acceptable to distribute so many small packages, or  
must we accept packaged groups even though it may discourage reuse?

T.