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 <bkl...@rksystems.com
<mailto:bkl...@rksystems.com>> wrote:
On Sun, Feb 25, 2018 at 6:18 PM, Mark Hammond
<mhamm...@skippinet.com.au <mailto:mhamm...@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
_______________________________________________
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32
