Mark: adodbapi.py is now in the pywin32 CVS. It is the version I have been running for a few months, there are differences only in documentation compared to the adodbapi CVS source tree. There are three outstanding issues, very minor, which I will address in the next few weeks, and will update the source here as soon as I have confidence in the newer version.** I did not want to miss a release window by trying for a perfect module.
I made a new sub-tree as you suggested. Unfortunately, I blew my first try and created a tree one level too high. I have sent in a support request for sourceforge to prune off my incorrect entry. Hopefully they will be able to do that before anyone does a check out of the error. Makes me feel really clumsy! I have not made any changes to setup.py -- so nothing will be installed until you add the code to do that. I am loath to mess with the installer myself, especially after having just made such a major foul-up on CVS. (Grrrr!) -- Vernon ---- On Aug 24, 2007 7:09 PM, Mark Hammond <[EMAIL PROTECTED]> wrote: > Just following up from Roger's comments (which I agree with): > > > The existing directory tree looks like this: > > -- adodbapi-2.1 > > ..--adodbapi > > ....--__init__.py > > ....--adodbapi.py > > ..--tests > > ....--adodbapitest.py > > ....--adodbapitestconfig.py > > ....--adbapi20.py (and so forth) > > ..--license.txt > > ..--readme.txt > > ..--setup.py > > > > I understand nothing about the magic whereby the source in the CVS tree > > becomes the install file that I run on a target system. So my question > > is: > > would /pywin32/adodbapi/adodbapy/adodbapi.py be the correct place to > > Did you mean 'adodbapy' there? > > > put the source? > > I'd be inclined to drop a level here by making 'tests' a sub-package. So > you would end up with: > > -- adodbapi > ..--__init__.py > ..--adodbapi.py > ..--tests > ....--adodbapitest.py > ....--adodbapitestconfig.py > ....--adbapi20.py (and so forth) > ..--license.txt > ..--readme.txt > > and presumably: > ..--setup.py > > will no longer be necessary (I don't think its worth still supporting > creating a stand-alone package). On the other hand, this may not scale as > well for the future (eg, 'docs' would need to be a child of the package > too > - but is that really a problem?). I'll leave this as your call though. > > Cheers, > > Mark > > >
_______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32