Hi, Vernon. I'm afraid I'm going to start sounding like an annoying
nag. :-) If you really want help with this project, you need to meet
me half way. If you're swamped with work right now, please at least
write back and say something like "I'm buried under a project right
now, and I won't be able to get back to you until next Friday." If
you're in hospital with a serious illness, I sincerely apologize and
I'll back off. If you'd prefer to take this thread offline, that's
fine with me, too.
I asked for guidance in getting the regression tests running (if we're
going to attract maintainers, one of the first things that needs to
happen is for the configuration script for the test suite to be made
much simpler to adapt to a specific platform, with all of the values
which need to be modified collected in one place with clear
documentation for what each of them means), but I didn't see anything
from you in response to that request, so I plunged in on my own. I've
got the SQL Server and Access tests running, and expect it won't be
too long before I've got the other back ends set up and plugged in. I
ran into two problems with the Access tests. The first is that
setuptestframework.py tries to copy a file from
../examples/adotest.mdb and that file doesn't exist (except perhaps on
your own machine). I solved that by firing up Access and creating the
missing file myself. The second problem is that one of the tests in
the suite fails. From the error message, it appears that the package
(or perhaps something else in the stack) is trying to treat a binary
value as a string (note the presence of the null terminator at the end
of the value and the extra quote marks in the repr() output):
C:\Python\Lib\site-packages\adodbapi\test>adodbapitest.py
2.7.13 (default, Jun 26 2017, 14:28:43) [MSC v.1500 64 bit (AMD64)]
node=xp: is64bit.os()= True, is64bit.Python()= True
adodbapi v2.6.0.7
testADOdbapiConfig.py v 2.6.0.A00
...copying test ACCESS db to
c:\users\bkline\appdata\local\temp\adodbapi_test\xx_COU8KEJ7K.mdb
...Testing ACCESS connection...
(successful)
...Testing MS-SQL login...
(successful)
Unit tests version 2.6.0.6 for adodbapi
Default Date Converter is <adodbapi.apibase.pythonDateTimeConverter
object at 0x0000000005970C18>
...............................F.......................................................................
======================================================================
FAIL: testDataTypeBinary (__main__.TestADOwithAccessDB)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Python\Lib\site-packages\adodbapi\test\adodbapitest.py",
line 395, in testDataTypeBinary
allowedReturnValues=arv)
File "C:\Python\Lib\site-packages\adodbapi\test\adodbapitest.py",
line 314, in helpTestDataType
'Value "%s" not in %s' % (repr(rs[0]), allowedReturnValues))
AssertionError: Value "'\x07\x00\xe2@\x00'" not in ['\x07\x00\xe2@*',
<read-only buffer for 0x0000000005183990, size -1, offset 0 at
0x0000000005A0D6C0>, '\x07\x00\xe2@*']
----------------------------------------------------------------------
Ran 103 tests in 8.394s
FAILED (failures=1)
I get the same failure if I use a more modern .accdb file.
Again, I apologize for this blunt message, but you've done some good
work on this package, and it's worth getting it back on the road.
Regards,
Bob Kline
On Mon, Feb 19, 2018 at 11:59 AM, Bob Kline <bkl...@rksystems.com> wrote:
> On Mon, Feb 19, 2018 at 11:18 AM, Vernon D. Cole <vernondc...@gmail.com>
> wrote:
>
>> Sounds like a good plan.
>
> As in, "yes, let's consolidate the project in one place (under pywin
> on GitHub)"? Or did you mean "yes, I agree we should have the
> discussion about whether we have to maintain the package in more than
> one place"? If the former, I'll be happy to get the ball rolling by
> starting the analysis for topping up the GitHub repo from the
> SourceForge oledbapi repo. If the latter, I guess the first step in
> that discussion would be for you to lay out the reason(s) why it
> wouldn't work to maintain the project just on GitHub (under pywin). Or
> perhaps you intended some third interpretation of "good plan."
>
> Cheers,
> Bob
>
>>
>> On Feb 19, 2018 04:57, "Bob Kline" <bkl...@rksystems.com> wrote:
>>>
>>> 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
>
>
>
> --
> Bob Kline
> http://www.rksystems.com
> mailto:bkl...@rksystems.com
--
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
