mini component distribution question

[Eric S. Johansson]

Ben Finney wrote:
> "Eric S. Johansson" <esj at harvee.org> writes:
>> Ben Finney wrote:
> setuptools allows downloads and/or installs from any specified 
> location. The Cheeseshop is just a convenient default location.
> 
>>> - use easy_install to automatically download and install them 
>>> when the main package is installed
>> This implies the need for two different methods of program 
>> propagation. First from the cheese shop, second from your source 
>> code sandbox as you are debugging etc.
> 
> No. setuptools only attempts to download a package if it's not 
> already installed. You merely need to ensure that your own 
> development build process installs the packages you want to be 
> tested.

setup tools should also download the package if the version of the 
package changed at the repository site.

however, I still say there are two different methods of program 
propagation, one for development and the other for preproduction and 
production.  when testing in the local environment, I tend to edit and 
test from my code management sandbox and cp out to testing.  Makes 
things simple unless I'm changing something that's in the Python module 
hierarchy.  Then it gets messy and I need to alter the search path.  I 
test, I get happy with the code, I package.  Then I install locally and 
if I didn't forget to remove the search path alterations, I might get a 
valid test result.

>> I really need to find a decent way of placing individual components
>>  under source code control.  I can barely cope with 3 darcs or cvs 
>> repositories gathered into one application, I'm not looking forward
>> to more. :-)
> 
> Develop and test them separately. Each modular component should have 
> its own test suite, to be run when than component is built; but 
> should be treated as a black box by anything else which uses it.

I know, that's the theory and has been the theory for the past 30+ years 
in software development. but what you suggest does not solve the problem 
that I am describing.  The problem is that the overhead of creating a 
source code repository and associated packages (not to mention test 
suites etc.) for a single module file is too high.  source code 
repository tools, test suites, packaged tools all count on the fact that 
you have a sufficient body of code making the overhead of the additional 
tools worthwhile.  for example, would you use the GNU autoconfiguration 
tool for a single C program of only a few hundred lines?  Heck, would 
you even use make? I know I wouldn't.

The same judgment call goes into the python packaging tools.  I rarely 
build a module.  I usually just shove the file in a separate directory 
and change the search path.  It's easier and less human overhead.

I was hoping someone had been reasonably clever and developed a system 
where individual components could be aggregated into one source code 
repository yet distributed separately with a minimum of manual 
intervention required.  Otherwise, if packaging takes more than 15-20 
minutes per small component, it's easier to use other less savory 
techniques.

in the meantime, I'll read up more on the egg stuff and think seriously 
about expanding raging dormouse (an automatic build and such tool I 
developed a couple of years ago.

Ben, thanks for the pointers.  I appreciate the reference.

--- eric