Mailing List Archive

On Tue, 11 Apr 2023 at 14:20, Mike Dewhirst <miked@dewhirst.com.au> wrote:
>
> It seems Christoph Gohlke has been cut adrift and his extremely valuable
> web page ...
>
> https://www.lfd.uci.edu/~gohlke/pythonlibs/
>
> ... turned into an archive getting staler by the day.
>
> What does the Python Software Foundation and the community think about this?

My personal view? Windows is *really really really* hard to support,
and ONE PERSON did a stellar job of supporting the platform for an
incredibly long job.

I don't know if he'll ever read this, but if he does, thank you
Christoph for your amazing contribution to the community.

The fact that we have a problem now is a testament to the length of
time that we *didn't* have a problem, thanks to him.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

On 11/04/2023 5:21 pm, Chris Angelico wrote:
> On Tue, 11 Apr 2023 at 14:20, Mike Dewhirst<miked@dewhirst.com.au> wrote:
>> It seems Christoph Gohlke has been cut adrift and his extremely valuable
>> web page ...
>>
>> https://www.lfd.uci.edu/~gohlke/pythonlibs/
>>
>> ... turned into an archive getting staler by the day.
>>
>> What does the Python Software Foundation and the community think about this?
> My personal view? Windows is *really really really* hard to support,
> and ONE PERSON did a stellar job of supporting the platform for an
> incredibly long job.

I have to agree - but what you are really saying is that without
Christoph, Python on Windows is

*really really really*

not viable.

Mike


>
> I don't know if he'll ever read this, but if he does, thank you
> Christoph for your amazing contribution to the community.
>
> The fact that we have a problem now is a testament to the length of
> time that we *didn't* have a problem, thanks to him.
>
> ChrisA


--
Signed email is an absolute defence against phishing. This email has
been signed with my private key. If you import my public key you can
automatically decrypt my signature and be sure it came from me. Your
email software can handle signing.

On Tue, 11 Apr 2023 at 18:22, Mike Dewhirst <miked@dewhirst.com.au> wrote:
>
> On 11/04/2023 5:21 pm, Chris Angelico wrote:
>
>> My personal view? Windows is *really really really* hard to support,
>> and ONE PERSON did a stellar job of supporting the platform for an
>> incredibly long job.
>
>
> I have to agree - but what you are really saying is that without Christoph, Python on Windows is
>
> *really really really*
>
> not viable.
>

This may well be true, but before writing Windows off completely [1],
do check out some of the commercial distributions. It may be that it's
possible to do everything through Conda, for instance.

[1] Much as I would like to, this isn't a good idea
--
https://mail.python.org/mailman/listinfo/python-list

What’s the problem now? Is it with python on windows? I use python on windows so I’d like to know. Thanks

Sent from my iPhone

> On Apr 11, 2023, at 2:24 AM, Chris Angelico <rosuav@gmail.com> wrote:
>
> ?On Tue, 11 Apr 2023 at 14:20, Mike Dewhirst <miked@dewhirst.com.au> wrote:
>>
>> It seems Christoph Gohlke has been cut adrift and his extremely valuable
>> web page ...
>>
>> https://www.lfd.uci.edu/~gohlke/pythonlibs/
>>
>> ... turned into an archive getting staler by the day.
>>
>> What does the Python Software Foundation and the community think about this?
>
> My personal view? Windows is *really really really* hard to support,
> and ONE PERSON did a stellar job of supporting the platform for an
> incredibly long job.
>
> I don't know if he'll ever read this, but if he does, thank you
> Christoph for your amazing contribution to the community.
>
> The fact that we have a problem now is a testament to the length of
> time that we *didn't* have a problem, thanks to him.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list

On Tue, 11 Apr 2023 at 20:15, Jim Schwartz <jschwar@sbcglobal.net> wrote:
>
> What’s the problem now? Is it with python on windows? I use python on windows so I’d like to know. Thanks
>

Python itself is fine, but a lot of third-party packages are hard to
obtain. So if you need numpy, for instance, or psycopg2, you might
need to find an alternative source.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

On Tue, 11 Apr 2023 at 12:01, Chris Angelico <rosuav@gmail.com> wrote:
>
> On Tue, 11 Apr 2023 at 20:15, Jim Schwartz <jschwar@sbcglobal.net> wrote:
> >
> > What’s the problem now? Is it with python on windows? I use python on windows so I’d like to know. Thanks
> >
>
> Python itself is fine, but a lot of third-party packages are hard to
> obtain. So if you need numpy, for instance, or psycopg2, you might
> need to find an alternative source.

Both numpy and psycopg2 have binary wheels for Windows that can be pip
installed from PyPI. I haven't used psycopg2 myself and I don't use
Windows so I can't say if there is any difficulty using them but I
presume that they can install and run just fine. Certainly the numpy
wheels have been there for Windows for years and work just fine.
Before numpy provided wheels they also provided MSI installers for
Windows anyway so there was always an alternative to Christoph's
stack.

Christoph's Windows binaries project predated the wheel format and so
the alternative options have improved massively since then. I presume
that there are some projects where Christoph's binaries are still the
only non-conda option (besides build yourself). I would not be
surprised if all of those are installable by conda though and we are
probably talking about projects that would seem obscure to most Python
users.

Certainly for the more widely used libraries like numpy installing
binaries with pip is not a problem these days on Windows or other
popular OS. I notice that psycopg2 *only* provides binaries for
Windows and not e.g. OSX or Linux but the list of binaries provided by
numpy is extensive with the current release listing wheels for all
combinations of CPython 3.8-3.11, win32, win amd64, manylinux amd64,
manylinux aarch64, OSX x64, OSX arm64:
https://pypi.org/project/numpy/1.24.2/#files

The difference now since the days when Cristoph started generating and
hosting binaries is that it is typically expected that a project like
numpy should produce its own binary wheels for popular platforms and
host them on PyPI. Of course that is a burden on the numpy maintainers
but tooling for this is much better than it used to be with things
like cibuildwheel, free CI systems including Windows/OSX runners etc.
It is *much* easier for a project to support generating Windows wheels
now than it used to be and to a certain extent it just forms part of
the normal CI setup that a project like numpy would want to have
anyway.

--
Oscar
--
https://mail.python.org/mailman/listinfo/python-list

Op 11/04/2023 om 12:58 schreef Chris Angelico:
> On Tue, 11 Apr 2023 at 20:15, Jim Schwartz <jschwar@sbcglobal.net> wrote:
> >
> > What’s the problem now? Is it with python on windows? I use python on windows so I’d like to know. Thanks
> >
>
> Python itself is fine, but a lot of third-party packages are hard to
> obtain. So if you need numpy, for instance, or psycopg2, you might
> need to find an alternative source.
These days I use pip to install packages, and so far for the things I
need it simply works. "pip install numpy" works, same for psycopg2,
pillow, pandas, and other packages I use. Conda should work too, for
those who use the Anaconda Python distribution. I honestly don't even
know how it's done: are there some kind souls who provide the wheels
(binary packages) for all those things, or if there is maybe a build
farm that does the hard work to make things easy for us.

In the past I've used Christoph Gohlke's site and I'm very grateful for
the service it provided, but these days I don't really need it anymore,
luckily.

--
"Ever since I learned about confirmation bias, I've been seeing
it everywhere."
-- Jon Ronson

--
https://mail.python.org/mailman/listinfo/python-list

On 2023-04-11 12:54:05 +0100, Oscar Benjamin wrote:
> Certainly for the more widely used libraries like numpy installing
> binaries with pip is not a problem these days on Windows or other
> popular OS. I notice that psycopg2 *only* provides binaries for
> Windows and not e.g. OSX or Linux

For Linux there is a separate package psycopg2-binary on PyPI.
That split happened a few years ago and I forgot why it was necessary.
For the distributions I use (Debian and Ubuntu) both packages work (but
for the source package I need to install the necessary development
packages first).

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

On Tue, 11 Apr 2023 at 21:55, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
>
> Both numpy and psycopg2 have binary wheels for Windows that can be pip
> installed from PyPI.

Ah good. It's been a long time since I've needed to care about
Windows, so I'm a bit out of the loop. That's good news. While not at
all detracting from his amazing contributions over the years, I'm
delighted that it's less necessary now.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

On 4/11/2023 6:58 AM, Chris Angelico wrote:
> On Tue, 11 Apr 2023 at 20:15, Jim Schwartz <jschwar@sbcglobal.net> wrote:
>>
>> What’s the problem now? Is it with python on windows? I use python on windows so I’d like to know. Thanks
>>
>
> Python itself is fine, but a lot of third-party packages are hard to
> obtain. So if you need numpy, for instance, or psycopg2, you might
> need to find an alternative source.

I've noticed a big change in the last few years in that PyPi has many,
many amd-64 packages than it used to in the heyday of Christoph Gohlke's
efforts. I haven't needed to go there for some time whereas I used to
need to all the time. So if I "need numpy, for instance, or psycopg2"
for Windows, I get them from PyPi.

Yes, I know that some projects haven't caught up to Python 3.11x yet.
And I'm glad I haven't needed to create a binary wheel for Windows
myself. But the situation is way better than it used to be. I've had
more trouble with Python and Python packages on Linux than on Windows.

--
https://mail.python.org/mailman/listinfo/python-list

On 4/11/23 06:03, Roel Schroeven wrote:
> Op 11/04/2023 om 12:58 schreef Chris Angelico:

>> Python itself is fine, but a lot of third-party packages are hard to
>> obtain. So if you need numpy, for instance, or psycopg2, you might
>> need to find an alternative source.
> These days I use pip to install packages, and so far for the things I
> need it simply works. "pip install numpy" works, same for psycopg2,
> pillow, pandas, and other packages I use. Conda should work too, for
> those who use the Anaconda Python distribution. I honestly don't even
> know how it's done: are there some kind souls who provide the wheels
> (binary packages) for all those things, or if there is maybe a build
> farm that does the hard work to make things easy for us.
>
> In the past I've used Christoph Gohlke's site and I'm very grateful for
> the service it provided, but these days I don't really need it anymore,
> luckily.

The deal really is, the instant a new Python version drops (3.11, 3.12,
etc.) a million people rush to install it, some of whom should know
better and be more patient. 3rd party packages are their own projects,
some have binary wheels ready on Python release day, some soon after,
some months after. That's the main hole this site filled in more recent
times: for people who feel they must jump forward but their key packages
were not yet ready, they were probably here. (I should add - it's not
always impatience, sometimes folks are also being proactive and want to
test Python betas, etc. so they're prepared, and they'll of course hit
the same problem of some wheels not being available).

There's even a "readiness" site folks can check (also volunteer-run),

https://pyreadiness.org/

but often the lure of the new shiny thing just wins out. I predict
we'll have a flood of anguish again in the fall when 3.12.0 comes out.

--
https://mail.python.org/mailman/listinfo/python-list

On Tue, 11 Apr 2023 at 14:55, Mats Wichmann <mats@wichmann.us> wrote:
>
> On 4/11/23 06:03, Roel Schroeven wrote:
> > Op 11/04/2023 om 12:58 schreef Chris Angelico:
>
> >> Python itself is fine, but a lot of third-party packages are hard to
> >> obtain. So if you need numpy, for instance, or psycopg2, you might
> >> need to find an alternative source.
> > These days I use pip to install packages, and so far for the things I
> > need it simply works. "pip install numpy" works, same for psycopg2,
> > pillow, pandas, and other packages I use. Conda should work too, for
> > those who use the Anaconda Python distribution. I honestly don't even
> > know how it's done: are there some kind souls who provide the wheels
> > (binary packages) for all those things, or if there is maybe a build
> > farm that does the hard work to make things easy for us.
> >
> > In the past I've used Christoph Gohlke's site and I'm very grateful for
> > the service it provided, but these days I don't really need it anymore,
> > luckily.
>
> The deal really is, the instant a new Python version drops (3.11, 3.12,
> etc.) a million people rush to install it, some of whom should know
> better and be more patient. 3rd party packages are their own projects,
> some have binary wheels ready on Python release day, some soon after,
> some months after.

You can hardly blame a lot of people for doing this. A seb search for
"download python" gives this as the first hit:
https://www.python.org/downloads/

I am guessing that the release process automatically updates that page
so that the minute 3.12 gets released the big yellow button will
suggest downloading 3.12.0 as the default option.

Perhaps it is really package authors who should be getting a release
out that is compatible with Python 3.12 before 3.12 itself is
released. It's tricky though because as a maintainer it makes more
sense to wait until you see the finished 3.12 product before making a
release that is fully tested with it (even if you are testing the
alphas etc in CI and making incremental fixes before 3.12 is
released).

The other option could be changing the downloads page so that it does
not suggest 3.12.0 as the default option until it is clear that at
least some baseline of widely used packages have uploaded compatible
wheels.

--
Oscar
--
https://mail.python.org/mailman/listinfo/python-list

On 4/11/23 11:48, Oscar Benjamin wrote:
> On Tue, 11 Apr 2023 at 14:55, Mats Wichmann <mats@wichmann.us> wrote:
>>
>> On 4/11/23 06:03, Roel Schroeven wrote:
>>> Op 11/04/2023 om 12:58 schreef Chris Angelico:
>>
>>>> Python itself is fine, but a lot of third-party packages are hard to
>>>> obtain. So if you need numpy, for instance, or psycopg2, you might
>>>> need to find an alternative source.
>>> These days I use pip to install packages, and so far for the things I
>>> need it simply works. "pip install numpy" works, same for psycopg2,
>>> pillow, pandas, and other packages I use. Conda should work too, for
>>> those who use the Anaconda Python distribution. I honestly don't even
>>> know how it's done: are there some kind souls who provide the wheels
>>> (binary packages) for all those things, or if there is maybe a build
>>> farm that does the hard work to make things easy for us.
>>>
>>> In the past I've used Christoph Gohlke's site and I'm very grateful for
>>> the service it provided, but these days I don't really need it anymore,
>>> luckily.
>>
>> The deal really is, the instant a new Python version drops (3.11, 3.12,
>> etc.) a million people rush to install it, some of whom should know
>> better and be more patient. 3rd party packages are their own projects,
>> some have binary wheels ready on Python release day, some soon after,
>> some months after.
>
> You can hardly blame a lot of people for doing this. A seb search for
> "download python" gives this as the first hit:
> https://www.python.org/downloads/
>
> I am guessing that the release process automatically updates that page
> so that the minute 3.12 gets released the big yellow button will
> suggest downloading 3.12.0 as the default option.

Yes, you're quite right about that.

> Perhaps it is really package authors who should be getting a release
> out that is compatible with Python 3.12 before 3.12 itself is
> released. It's tricky though because as a maintainer it makes more
> sense to wait until you see the finished 3.12 product before making a
> release that is fully tested with it (even if you are testing the
> alphas etc in CI and making incremental fixes before 3.12 is
> released).

If you can find the incantation there are often pending builds for
packages that need binary wheels, it may be "pip --pre" or it may be
pointing to test.pypi.org... or there may not be. The projects may not
tell you. And for many less experienced users (and yes this is a known
issue), they have no idea they need to look.

> The other option could be changing the downloads page so that it does
> not suggest 3.12.0 as the default option until it is clear that at
> least some baseline of widely used packages have uploaded compatible
> wheels.

There's been some suggestion of that before. Apparently the choice of
what goes there is at least a bit political. Like many projects, I
believe python prefers to recommend "the latest and best release", while
user prudence (and especially organizational prudence) tends to say
"hold off for a while until it's been fully vetted, and the ecosystem
catches up". I don't think we can cast too much blame on either: I don't
expect Microsoft will say "Don't download Windows 12 for the first six
months", even if they know perfectly well that many enterprise customers
will take an approach like that.

Not sure there's any really good answer, TBH.



--
https://mail.python.org/mailman/listinfo/python-list

On 4/11/23 11:48, Oscar Benjamin wrote:
> You can hardly blame a lot of people for doing this. A seb search for
> "download python" gives this as the first hit:
> https://www.python.org/downloads/

Very true, but it points to the difference between how people install
Python on Windows compared to Linux, which is what Chris was probably
referring to when he said Windows was a nightmare to support. Usually
when a full version bump of python hits my distros, all the other
packages that need to be rebuilt get rebuilt and install along with the
new python package. Or often the older version of Python is patched and
continued to be used, not requiring new packages. So most linux users
never have to go searching for an appropriate version of Numpy, etc.

Whereas Windows only recently has gained a package manager, and as near
as I can tell is not widely used outside of serious developers who use
Visual Studio. And to make matters worse, MS offers Python in the
Windows Store, which is its own thing and causes much confusion with
users who often end up with more than one version of Python installed.
And nevermind the MingW/MSVC split that affects the distribution of
pre-built binaries, although MS's move to the universal C runtime dll
system might fix this finally (unless C++ is involved).

These are all extremely hard problems to solve, and every solution has
its drawbacks, including the packaging systems used by Linux.
Especially by an open source organization like the PSF.
--
https://mail.python.org/mailman/listinfo/python-list

Well thank you Christoph Gohlke and thank you Ian Bicking and colleagues.

I just used pip to nakedly install psycopg2 and Pillow without a hitch.
My distrust of Windows has kept me going back to Christoff's well for
years.

Maybe it is time to assume innocence unless proven guilty ;-)

Thanks to all who showed me the way.

Cheers

Mike

On 11/04/2023 11:39 pm, Thomas Passin wrote:
> On 4/11/2023 6:58 AM, Chris Angelico wrote:
>> On Tue, 11 Apr 2023 at 20:15, Jim Schwartz <jschwar@sbcglobal.net>
>> wrote:
>>>
>>> What’s the problem now?  Is it with python on windows?  I use python
>>> on windows so I’d like to know. Thanks
>>>
>>
>> Python itself is fine, but a lot of third-party packages are hard to
>> obtain. So if you need numpy, for instance, or psycopg2, you might
>> need to find an alternative source.
>
> I've noticed a big change in the last few years in that PyPi has many,
> many amd-64 packages than it used to in the heyday of Christoph
> Gohlke's efforts. I haven't needed to go there for some time whereas I
> used to need to all the time.  So if I "need numpy, for instance, or
> psycopg2" for Windows, I get them from PyPi.
>
> Yes, I know that some projects haven't caught up to Python 3.11x yet.
> And I'm glad I haven't needed to create a binary wheel for Windows
> myself.  But the situation is way better than it used to be.  I've had
> more trouble with Python and Python packages on Linux than on Windows.
>


--
Signed email is an absolute defence against phishing. This email has
been signed with my private key. If you import my public key you can
automatically decrypt my signature and be sure it came from me. Your
email software can handle signing.

Sadly Windows is still in the dock. The jury is still out.

Turns out the "without a hitch" was based on cached wheels.

I'm going to start from scratch with new projects using Pythons 3.8,
3.10 and 3.11 and report back.

Cheers

Mike

On 12/04/2023 6:13 pm, Mike Dewhirst wrote:
> Well thank you Christoph Gohlke and thank you Ian Bicking and colleagues.
>
> I just used pip to nakedly install psycopg2 and Pillow without a
> hitch. My distrust of Windows has kept me going back to Christoff's
> well for years.
>
> Maybe it is time to assume innocence unless proven guilty ;-)
>
> Thanks to all who showed me the way.
>
> Cheers
>
> Mike
>
> On 11/04/2023 11:39 pm, Thomas Passin wrote:
>> On 4/11/2023 6:58 AM, Chris Angelico wrote:
>>> On Tue, 11 Apr 2023 at 20:15, Jim Schwartz <jschwar@sbcglobal.net>
>>> wrote:
>>>>
>>>> What’s the problem now?  Is it with python on windows?  I use
>>>> python on windows so I’d like to know. Thanks
>>>>
>>>
>>> Python itself is fine, but a lot of third-party packages are hard to
>>> obtain. So if you need numpy, for instance, or psycopg2, you might
>>> need to find an alternative source.
>>
>> I've noticed a big change in the last few years in that PyPi has
>> many, many amd-64 packages than it used to in the heyday of Christoph
>> Gohlke's efforts. I haven't needed to go there for some time whereas
>> I used to need to all the time.  So if I "need numpy, for instance,
>> or psycopg2" for Windows, I get them from PyPi.
>>
>> Yes, I know that some projects haven't caught up to Python 3.11x yet.
>> And I'm glad I haven't needed to create a binary wheel for Windows
>> myself.  But the situation is way better than it used to be.  I've
>> had more trouble with Python and Python packages on Linux than on
>> Windows.
>>
>
>
>


--
Signed email is an absolute defence against phishing. This email has
been signed with my private key. If you import my public key you can
automatically decrypt my signature and be sure it came from me. Your
email software can handle signing.

On 4/12/2023 8:59 AM, Mike Dewhirst wrote:
> Sadly Windows is still in the dock. The jury is still out.
>
> Turns out the "without a hitch" was based on cached wheels.
>
> I'm going to start from scratch with new projects using Pythons 3.8,
> 3.10 and 3.11 and report back.

Sorry for the length to come, but here's what I've got so far - on
Windows, python 3.11 - all pip-installed. Note especially numpy, scipy,
statsmodels, mysql-connector-python, scikit-learn -

C:\Users\tom>py -V
Python 3.11.3

C:\Users\tom>py -m pip list
Package Version
----------------------------- -------------------
accessible-pygments 0.0.4
alabaster 0.7.13
argcomplete 3.0.5
asciidoc 10.2.0
asciidoc3 3.2.3
astroid 2.15.2
asttokens 2.2.1
async-generator 1.10
attrs 22.2.0
Babel 2.12.1
beautifulsoup4 4.12.1
black 23.3.0
bleach 6.0.0
bokeh 2.4.3
build 0.10.0
certifi 2022.12.7
cffi 1.15.1
cftime 1.6.2
charset-normalizer 3.1.0
click 8.1.3
colorama 0.4.6
colorcet 3.0.1
contourpy 1.0.7
csaps 1.1.0
cycler 0.11.0
datatable 1.1.0a0+pr3440.2228
defusedxml 0.7.1
dialite 0.5.3
dill 0.3.6
docutils 0.19
exceptiongroup 1.1.1
fastjsonschema 2.16.3
fire 0.5.0
flexx 0.8.4
fonttools 4.39.3
frechetdist 0.6
GenDoc 1.0.1
ghp-import 2.1.0
h11 0.14.0
holoviews 1.15.4
idna 3.4
imageio 2.27.0
imagesize 1.4.1
importlib-metadata 6.1.0
iniconfig 2.0.0
isort 5.12.0
jaraco.classes 3.2.3
jill 0.11.3
Jinja2 3.1.2
joblib 1.2.0
jsonschema 4.17.3
jupyter_client 8.1.0
jupyter_core 5.3.0
jupyterlab-pygments 0.2.2
karma-sphinx-theme 0.0.8
keyring 23.13.1
kiwisolver 1.4.4
lazy_loader 0.2
lazy-object-proxy 1.9.0
leo 6.7.2
linkify-it-py 2.0.0
localreg 0.5.0
lxml 4.9.2
lz4 4.3.2
Markdown 3.3.7
markdown-it-py 2.2.0
MarkupSafe 2.1.2
matplotlib 3.6.3
mccabe 0.7.0
mdit-py-plugins 0.3.5
mdurl 0.1.2
mergedeep 1.3.4
meta 1.0.2
mistune 2.0.5
mizani 0.8.1
mkdocs 1.4.2
mkdocs-exclude 1.0.2
more-itertools 9.1.0
mpmath 1.3.0
multidict 6.0.4
mypy 1.2.0
mypy-extensions 1.0.0
mysql-connector-python 8.0.32
mysqlclient 2.1.1
nbclient 0.7.3
nbconvert 7.3.0
nbformat 5.8.0
nest-asyncio 1.5.6
netCDF4 1.6.3
networkx 3.1
nltk 3.8.1
numpy 1.24.2
outcome 1.2.0
packaging 23.0
palettable 3.3.1
pandas 2.0.0
pandoc 2.3
pandocfilters 1.5.0
panel 0.14.4
param 1.13.0
pathspec 0.11.1
patsy 0.5.3
pep517 0.13.0
Pillow 9.5.0
pip 23.0.1
pipx 1.2.0
pkginfo 1.9.6
platformdirs 3.2.0
plotly 5.14.1
plotnine 0.10.1
pluggy 1.0.0
plumbum 1.8.1
ply 3.11
progressbar2 4.2.0
protobuf 4.22.1
pscript 0.7.7
pwlf 2.2.1
pycodestyle 2.10.0
pycparser 2.21
pyct 0.5.0
pydata-sphinx-theme 0.13.3
pyDOE 0.3.8
pyenchant 3.2.2
pyflakes 3.0.1
pygam 0.9.0
Pygments 2.14.0
pylint 2.17.2
pyparsing 3.0.9
pyperclip 1.8.2
pyproject_hooks 1.0.0
PyQt5 5.15.9
PyQt5-Qt5 5.15.2
PyQt5-sip 12.11.1
PyQt6 6.4.2
PyQt6-Qt6 6.4.3
PyQt6-sip 13.4.1
PyQt6-WebEngine 6.4.0
PyQt6-WebEngine-Qt6 6.4.3
PyQtWebEngine 5.15.6
PyQtWebEngine-Qt5 5.15.2
pyrsistent 0.19.3
pyshortcuts 1.8.3
PySocks 1.7.1
pytest 7.2.2
python-dateutil 2.8.2
python-dotenv 1.0.0
python-gnupg 0.5.0
python-utils 3.5.2
pytz 2023.3
pyviz-comms 2.2.1
PyWavelets 1.4.1
pywin32 306
pywin32-ctypes 0.2.0
PyYAML 6.0
pyyaml_env_tag 0.1
pyzmq 25.0.2
readme-renderer 37.3
regex 2023.3.23
requests 2.28.2
requests-futures 1.0.0
requests-toolbelt 0.10.1
rfc3986 2.0.0
rich 13.3.3
scaleogram 0.9.5
scikit-image 0.20.0
scikit-learn 1.2.2
scipy 1.10.1
seaborn 0.12.2
selenium 4.8.3
semantic-version 2.10.0
setuptools 67.6.1
six 1.16.0
sniffio 1.3.0
snowballstemmer 2.2.0
sortedcontainers 2.4.0
soupsieve 2.4
Sphinx 6.1.3
sphinx-panels 0.6.0
sphinx-rtd-theme 1.2.0
sphinxcontrib-applehelp 1.0.4
sphinxcontrib-devhelp 1.0.2
sphinxcontrib-htmlhelp 2.0.1
sphinxcontrib-jquery 4.1
sphinxcontrib-jsmath 1.0.1
sphinxcontrib-mermaid 0.8.1
sphinxcontrib-qthelp 1.0.3
sphinxcontrib-serializinghtml 1.1.5
statsmodels 0.13.5
tabulate 0.9.0
tenacity 8.2.2
termcolor 2.2.0
textblob 0.17.1
textual 0.18.0
threadpoolctl 3.1.0
tifffile 2023.3.21
tinycss2 1.2.1
tk 0.1.0
tomli 2.0.1
tomlkit 0.11.7
tornado 6.2
tqdm 4.65.0
traitlets 5.9.0
trio 0.22.0
trio-websocket 0.10.2
twine 4.0.2
types-docutils 0.19.1.7
typing_extensions 4.5.0
tzdata 2023.3
uc-micro-py 1.0.1
urllib3 1.26.15
userpath 1.8.0
watchdog 3.0.0
webdriver-manager 3.8.5
webencodings 0.5.1
webruntime 0.5.8
websockets 11.0.1
wget 3.2
wheel 0.40.0
Whoosh 2.7.4
windows-curses 2.3.1
wrapt 1.15.0
wsproto 1.2.0
xyzservices 2023.2.0
yapf 0.32.0
yarl 1.8.2
zipp 3.15.0

--
https://mail.python.org/mailman/listinfo/python-list

On 12/04/2023 10:59 pm, Mike Dewhirst wrote:
> Sadly Windows is still in the dock. The jury is still out.
>
> Turns out the "without a hitch" was based on cached wheels.
>
> I'm going to start from scratch with new projects using Pythons 3.8,
> 3.10 and 3.11 and report back.

Report summary:

pip install works well with Python 3.8 and 3.10 (and presumably 3.9) but
3.11 fails.

Report conclusion:

As indicated in this thread, pip cannot find Python 3.11 wheels and
therefore needs to compile from source. It is looking for Microsoft's
C++ compiler version 14.

I'll (gulp) attempt to swallow the Koolaid.

See error below ...

Cheers

Mike

(xreq) D:\Users\mike\envs\xreq>pip install -r requirements\dev.txt

...

Collecting psycopg2==2.9.3

  Downloading psycopg2-2.9.3.tar.gz (380 kB)

     --------------------------------------- 380.6/380.6 kB 6.0 MB/s eta 0:00:00

  Preparing metadata (setup.py) ... done

Collecting Pillow==9.1.1

  Downloading Pillow-9.1.1.tar.gz (49.8 MB)

     ---------------------------------------- 49.8/49.8 MB 4.5 MB/s eta 0:00:00

  Preparing metadata (setup.py) ... done

...

Installing collected packages: psycopg2, Pillow, ...

  DEPRECATION: psycopg2 is being installed using the legacy 'setup.py install' method, because it does not have a 'pyproject.toml' and the 'wheel' package is not installed. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found athttps://github.com/pypa/pip/issues/8559

  Running setup.py install for psycopg2 ... error

  error: subprocess-exited-with-error

  × Running setup.py install for psycopg2 did not run successfully.

  ? exit code: 1

  ??> [24 lines of output]

      D:\Users\mike\envs\xreq\Lib\site-packages\setuptools\config\setupcfg.py:508: SetuptoolsDeprecationWarning: The license_file parameter is deprecated, use license_files instead.

        warnings.warn(msg, warning_class)

      running install

      D:\Users\mike\envs\xreq\Lib\site-packages\setuptools\command\install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.

        warnings.warn(

      running build

      running build_py

      creating build

      creating build\lib.win-amd64-cpython-311

      creating build\lib.win-amd64-cpython-311\psycopg2

      copying lib\errorcodes.py -> build\lib.win-amd64-cpython-311\psycopg2

      copying lib\errors.py -> build\lib.win-amd64-cpython-311\psycopg2

      copying lib\extensions.py -> build\lib.win-amd64-cpython-311\psycopg2

      copying lib\extras.py -> build\lib.win-amd64-cpython-311\psycopg2

      copying lib\pool.py -> build\lib.win-amd64-cpython-311\psycopg2

      copying lib\sql.py -> build\lib.win-amd64-cpython-311\psycopg2

      copying lib\tz.py -> build\lib.win-amd64-cpython-311\psycopg2

      copying lib\_ipaddress.py -> build\lib.win-amd64-cpython-311\psycopg2

      copying lib\_json.py -> build\lib.win-amd64-cpython-311\psycopg2

      copying lib\_range.py -> build\lib.win-amd64-cpython-311\psycopg2

      copying lib\__init__.py -> build\lib.win-amd64-cpython-311\psycopg2

      running build_ext

      building 'psycopg2._psycopg' extension

      error: Microsoft Visual C++ 14.0 or greater is required. Get it with "Microsoft C++ Build Tools":https://visualstudio.microsoft.com/visual-cpp-build-tools/

      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.

error: legacy-install-failure

× Encountered error while trying to install package.

??> psycopg2

note: This is an issue with the package mentioned above, not pip.

hint: See above for output from the failure.

(xreq) D:\Users\mike\envs\xreq>




>
> Cheers
>
> Mike
>
> On 12/04/2023 6:13 pm, Mike Dewhirst wrote:
>> Well thank you Christoph Gohlke and thank you Ian Bicking and
>> colleagues.
>>
>> I just used pip to nakedly install psycopg2 and Pillow without a
>> hitch. My distrust of Windows has kept me going back to Christoff's
>> well for years.
>>
>> Maybe it is time to assume innocence unless proven guilty ;-)
>>
>> Thanks to all who showed me the way.
>>
>> Cheers
>>
>> Mike
>>
>> On 11/04/2023 11:39 pm, Thomas Passin wrote:
>>> On 4/11/2023 6:58 AM, Chris Angelico wrote:
>>>> On Tue, 11 Apr 2023 at 20:15, Jim Schwartz <jschwar@sbcglobal.net>
>>>> wrote:
>>>>>
>>>>> What’s the problem now?  Is it with python on windows?  I use
>>>>> python on windows so I’d like to know. Thanks
>>>>>
>>>>
>>>> Python itself is fine, but a lot of third-party packages are hard to
>>>> obtain. So if you need numpy, for instance, or psycopg2, you might
>>>> need to find an alternative source.
>>>
>>> I've noticed a big change in the last few years in that PyPi has
>>> many, many amd-64 packages than it used to in the heyday of
>>> Christoph Gohlke's efforts. I haven't needed to go there for some
>>> time whereas I used to need to all the time.  So if I "need numpy,
>>> for instance, or psycopg2" for Windows, I get them from PyPi.
>>>
>>> Yes, I know that some projects haven't caught up to Python 3.11x
>>> yet. And I'm glad I haven't needed to create a binary wheel for
>>> Windows myself.  But the situation is way better than it used to
>>> be.  I've had more trouble with Python and Python packages on Linux
>>> than on Windows.
>>>
>>
>>
>>
>
>
>


--
Signed email is an absolute defence against phishing. This email has
been signed with my private key. If you import my public key you can
automatically decrypt my signature and be sure it came from me. Your
email software can handle signing.

On 2023-04-13 02:27, Mike Dewhirst wrote:
> On 12/04/2023 10:59 pm, Mike Dewhirst wrote:
>> Sadly Windows is still in the dock. The jury is still out.
>>
>> Turns out the "without a hitch" was based on cached wheels.
>>
>> I'm going to start from scratch with new projects using Pythons 3.8,
>> 3.10 and 3.11 and report back.
>
> Report summary:
>
> pip install works well with Python 3.8 and 3.10 (and presumably 3.9) but
> 3.11 fails.
>
> Report conclusion:
>
> As indicated in this thread, pip cannot find Python 3.11 wheels and
> therefore needs to compile from source. It is looking for Microsoft's
> C++ compiler version 14.
>
> I'll (gulp) attempt to swallow the Koolaid.
>
> See error below ...
>
> Cheers
>
> Mike
>
> (xreq) D:\Users\mike\envs\xreq>pip install -r requirements\dev.txt
>
> ...
>
> Collecting psycopg2==2.9.3
>
>   Downloading psycopg2-2.9.3.tar.gz (380 kB)
>
>      --------------------------------------- 380.6/380.6 kB 6.0 MB/s eta 0:00:00
>
>   Preparing metadata (setup.py) ... done
>
> Collecting Pillow==9.1.1
>
>   Downloading Pillow-9.1.1.tar.gz (49.8 MB)
>
>      ---------------------------------------- 49.8/49.8 MB 4.5 MB/s eta 0:00:00
>
>   Preparing metadata (setup.py) ... done
>
> ...
>
> Installing collected packages: psycopg2, Pillow, ...
>
>   DEPRECATION: psycopg2 is being installed using the legacy 'setup.py install' method, because it does not have a 'pyproject.toml' and the 'wheel' package is not installed. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found athttps://github.com/pypa/pip/issues/8559
>
>   Running setup.py install for psycopg2 ... error
>
>   error: subprocess-exited-with-error
>
>   × Running setup.py install for psycopg2 did not run successfully.
>
>   ? exit code: 1
>
>   ??> [24 lines of output]
>
>       D:\Users\mike\envs\xreq\Lib\site-packages\setuptools\config\setupcfg.py:508: SetuptoolsDeprecationWarning: The license_file parameter is deprecated, use license_files instead.
>
>         warnings.warn(msg, warning_class)
>
>       running install
>
>       D:\Users\mike\envs\xreq\Lib\site-packages\setuptools\command\install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
>
>         warnings.warn(
>
>       running build
>
>       running build_py
>
>       creating build
>
>       creating build\lib.win-amd64-cpython-311
>
>       creating build\lib.win-amd64-cpython-311\psycopg2
>
>       copying lib\errorcodes.py -> build\lib.win-amd64-cpython-311\psycopg2
>
>       copying lib\errors.py -> build\lib.win-amd64-cpython-311\psycopg2
>
>       copying lib\extensions.py -> build\lib.win-amd64-cpython-311\psycopg2
>
>       copying lib\extras.py -> build\lib.win-amd64-cpython-311\psycopg2
>
>       copying lib\pool.py -> build\lib.win-amd64-cpython-311\psycopg2
>
>       copying lib\sql.py -> build\lib.win-amd64-cpython-311\psycopg2
>
>       copying lib\tz.py -> build\lib.win-amd64-cpython-311\psycopg2
>
>       copying lib\_ipaddress.py -> build\lib.win-amd64-cpython-311\psycopg2
>
>       copying lib\_json.py -> build\lib.win-amd64-cpython-311\psycopg2
>
>       copying lib\_range.py -> build\lib.win-amd64-cpython-311\psycopg2
>
>       copying lib\__init__.py -> build\lib.win-amd64-cpython-311\psycopg2
>
>       running build_ext
>
>       building 'psycopg2._psycopg' extension
>
>       error: Microsoft Visual C++ 14.0 or greater is required. Get it with "Microsoft C++ Build Tools":https://visualstudio.microsoft.com/visual-cpp-build-tools/
>
>       [end of output]
>
>   note: This error originates from a subprocess, and is likely not a problem with pip.
>
> error: legacy-install-failure
>
> × Encountered error while trying to install package.
>
> ??> psycopg2
>
> note: This is an issue with the package mentioned above, not pip.
>
> hint: See above for output from the failure.
>
> (xreq) D:\Users\mike\envs\xreq>
>
[snip]

C:\Users\mrab>py -3.11 -m pip install psycopg2
Collecting psycopg2
Downloading psycopg2-2.9.6-cp311-cp311-win_amd64.whl (1.2 MB)
---------------------------------------- 1.2/1.2 MB 2.4 MB/s eta
0:00:00
Installing collected packages: psycopg2
Successfully installed psycopg2-2.9.6

C:\Users\mrab>py -3.11 -m pip install Pillow
Requirement already satisfied: Pillow in c:\python311\lib\site-packages
(9.2.0)

--
https://mail.python.org/mailman/listinfo/python-list

On 4/12/23, Mike Dewhirst <miked@dewhirst.com.au> wrote:
>
> Collecting psycopg2==2.9.3

x86 and x64 wheels are available for Python 3.11 if you can use
Psycopg 2 version 2.9.5 or 2.9.6 instead of 2.9.3:

https://pypi.org/project/psycopg2/2.9.5/#files
https://pypi.org/project/psycopg2/2.9.6/#files
--
https://mail.python.org/mailman/listinfo/python-list

On 13/04/2023 12:00 pm, Eryk Sun wrote:
> On 4/12/23, Mike Dewhirst<miked@dewhirst.com.au> wrote:
>> Collecting psycopg2==2.9.3
> x86 and x64 wheels are available for Python 3.11 if you can use
> Psycopg 2 version 2.9.5 or 2.9.6 instead of 2.9.3:
>
> https://pypi.org/project/psycopg2/2.9.5/#files
> https://pypi.org/project/psycopg2/2.9.6/#files

Many thanks to both of you ...

I'll uninstall Microsoft Build Tools as soon as its finished installing
(37.3GB and I had to clear space for it)

Cheers

Mike




--
Signed email is an absolute defence against phishing. This email has
been signed with my private key. If you import my public key you can
automatically decrypt my signature and be sure it came from me. Your
email software can handle signing.