[python-win32] Bug reporting

[Mark Hammond]

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
> 
>