Ben Finney wrote: > "Eric S. Johansson" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
