On Mon, Feb 19, 2018 at 2:25 AM, Vernon D. Cole <vernondc...@gmail.com> wrote:
> I will try to clear this up as much as I can... Thanks very much for your reply, Vernon. > Adodbapi lives in two places, as a stand-alone project on Sourceforge, and > integrated with PyWin32. Well, I wouldn't go so far as saying it "lives" in the GitHub project; more like it's on life support. :-) As far as I can tell, it's never actually been usable from that repo, as the required apibase.py file didn't make it to the party. > The Sourceforge project is needed for Iron Python, and has more > documentation, and, originally, a faster upgrade cycle. I see, however, that the code to support IronPython is in both places, documentation can easily be enhanced, and (as you acknowledge) the upgrade cycle for the SourceForge project has gone walkabout. It would seem ideal (if nothing else, from the perspective of the attempt to attract more maintainers) if we didn't have to maintain two separate code bases. > The SF code was copied to pywin32 for easier installation and more > convenience, but the file layout is slightly different. I did not have the > capability to test the pywin32 installation so was unaware of the problem > until too late. Then I went to work for another company which did not use > Windows at all, so everything got kind of lost. > > The move of pywin32 to GitHub, along with improved testing there will help > to fix things. I am also building an SQL server test bench which I hope > will be permanent. A patch has been submitted to fix the "missing file" > problem, and I have changed my SF notifications to a different email address > that I check more frequently. > > The python-win project is the preferred maintenance place. Perhaps a note on the SourceForge page to that effect would be appropriate. > Meanwhile ... I am not getting any younger and an active back-up maintainer > for the home adodbapi project would be very welcome if someone were willing > to help out. At the present moment the "bus size" is one -- which is a bad > thing. I'm happy to do what I can, though as I pointed out in an earlier thread, you're younger than I am. :-) If you provide instructions for getting the regression tests running, I'll try to replicate them here. Let's first decide the question of how many places we're going to maintain the package. I vote for one (on GitHub). If (for whatever reason) it's necessary to maintain it in two places, let's (a) decide whether it's possible to keep the two places synchronized so they don't drift into forks of each other; (b) figure out how such synchronization will be accomplished; and most important (c) make it very clear in both locations what the relationship is between the two repositories, telling everyone which one should be used in which situation, where to file issue tracking tickets, etc. Thanks again for your willingness to bring this project back to life. -- Bob Kline http://www.rksystems.com mailto:bkl...@rksystems.com _______________________________________________ python-win32 mailing list python-win32@python.org https://mail.python.org/mailman/listinfo/python-win32