[python-win32] Bug reporting

[Vernon D. Cole]

I decided to meditate for a few days rather than answer immediately and
poorly.

After I took over maintenance of adodbapi in about 2003, I was struggling
with how to properly document
that most users (CPython) had to install pywin32 as a prerequisite. At that
time the odbc sub-module had a couple of bugs,
and ADO seemed to be all the future. Also pywin32's odbc module follows the
api 1.0 version.
I asked, and received a green light, to bundle adodbapi with pywin32.

When you (Mark) gave that okay, you had one stipulation: that the module
get "some support".

During the last few years I have failed to provide that support. That fact
causes me daily regret.
I want the opportunity to correct my failure. I also want to enable someone
else to be able to support the package
should the need arise, like if I have a stroke or something. I have already
survived cancer.
I understand that pywin32 support is "largely" just you, but adodbapi
support is _only_ just me -- a critical difference.

Here is what I propose:

1) This time, rather than copy a selected (major) part of the adodbapi
source files over to their pywin32 directory,
I would copy _all_ of the files.

2) Adjust adodbapi/MANIFEST.in and setup.py to create a proper PyPi
submission from that directory.

3) Adjust the pywin32 MANIFEST.in to include a subset of adodbapi files
that actually works.

4) Put a simple go/no-go test of adodbapi (perhaps ACCESS database only)
into the pywin32 test suite.

5) document in SourceForge that future updates will take place in the
pywin32 repo.
--
Vernon


On Mon, Feb 26, 2018 at 5:53 PM, Mark Hammond <mhammond at skippinet.com.au>
wrote:

> On 27/02/2018 5:40 am, Vernon D. Cole wrote:
>
>> Second: the effective "bus size" of the adodbapi repo is *one*. The other
>> three authorized maintainers are inactive.  Indeed, the way I got approved
>> as a maintainer 15 years ago (has it really been that long?) was to
>> document to SourceForge that the then-existing two maintainers were
>> unresponsive. Moving the working source into the pywin32 repo would solve
>> that problem.
>>
>
> It's not immediately clear that it would though. pywin32 itself has the
> exact same issue (ie, it's largely just me), and I don't use or know much
> about adodbapi - so it seems somewhat likely you'd have the same "bus size"
> - just on a different bus :)
>
> My research this morning suggests that by suitable editing of the
>> MANIFEST.in file in the pywin32 root, and the  /adodbapi/MANIFEST.in and
>> ./setup.py we could effectively send two seemingly independent (but source
>> locked) versions of adodbapi to PyPi.  That should keep both
>> CPython/pywin32 and IronPython use cases covered.  Should I pursue that?
>>
>
> When building pywin32 I don't send *any* versions of adodbapi to pypi, so
> I'm really not sure what that means. I'm reluctant to agree that building
> pywin32 will create many discrete wheels - I already need to upload wheels
> for each python version supported and for 64 and 32 bits and making the
> build and release process more convoluted doesn't sound like a win for me.
>
> So can you please explain in more detail what is being proposed here, and
> why it would be preferred to splitting adodbapi into its own repo on
> github, possibly including removal of it from pywin32 if the duplication
> causes problems?
>
> Cheers,
>
> Mark
>
> --
>> Vernon
>>
>>
>> I spent the morning reviewing the documentation for setuptools and wheels
>> and such.
>>
>>
>>
>> On Sun, Feb 25, 2018 at 7:35 PM, Bob Kline <bkline at rksystems.com <mailto:
>> bkline at rksystems.com>> wrote:
>>
>>     On Sun, Feb 25, 2018 at 6:18 PM, Mark Hammond
>>     <mhammond at skippinet.com.au <mailto:mhammond at skippinet.com.au>> wrote:
>>
>>     > 1) There's a relatively easy fix that can be made to the copy of
>> adodbapi
>>     > which is inside pywin32.
>>
>>     Right. Basically, I think what needs to happen is for the fork on
>>     GitHub to be brought in sync with the working code on SF. I'm going to
>>     guess it's not quite as simple as that, because we'd want to be
>>     careful to preserve any patches which got applied on GitHub, but
>>     didn't make it to the original repo. Don't know for sure that there
>>     are any, but we should check.
>>
>>     > 2) There's a concern regarding some IronPython bindings for
>> adodbapi which
>>     > aren't in pywin32 and Vernon was asking something whether they
>> should also
>>     > be included in pywin32.
>>
>>     As I understand it, the code to support IronPython is already included
>>     in what's on GitHub. I think Vernon's hoping that there's a way to
>>     script an export of just the adodbapi portion of your GitHub repo for
>>     the use of the IronPython users (who, as you correctly point out, have
>>     no use for the pywin32 bits). If that's possible (and I can't see why
>>     it wouldn't be, as GitHub is pretty easy to script), he would be able
>>     to avoid the tedium and risks involved in having to maintain the same
>>     code base in two different places. It would also eliminate the "where
>>     am I supposed to file bugs" confusion, as well as make it easier to
>>     persuade others to assist with maintenance of the code. Most of the
>>     adodbapi code is common for IronPython and CPython users, and I don't
>>     see that the presence of "if IronPython: ..." code in the
>>     mhammond/pywin32 repo does any harm (after all, it's already there and
>>     I'll bet no one has noticed).
>>
>>     I hope that makes things a little clearer. But this explanation is
>>     speculation on my part, and I should really let Vernon say what he
>>     means for #2.
>>
>>     Regards,
>>     Bob
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20180304/47e250b1/attachment.html>