Re: [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 > wrote:


On Sun, Feb 25, 2018 at 6:18 PM, Mark Hammond
> 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




___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

[Vernon D. Cole]

There are two problems with the existing SourceForge repo of adodbapi.

First, the manual copy of updates to the pywin32 code base can easily fail
-- as it did several years ago and I missed the resulting error which
remained unfixed for several releases of pywin32. That problem was
exacerbated by me moving to a new job where I never used Windows at all,
along with my test platform dying.

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.

So, it looks to me like moving the development copy of adodbapi source to
the pywin32 GitHub repo would be a Good Idea. But could that be easily done?

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?
--
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  wrote:

> On Sun, Feb 25, 2018 at 6:18 PM, Mark Hammond 
> 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
>
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32