eryk sun wrote, on Monday, May 15, 2017 5:52 AM
>
> On Mon, May 15, 2017 at 6:37 AM, Deborah Swanson
> <pyt...@deborahswanson.net> wrote:
> >
> > Where did you find recordclass-0.4.3-cp34-cp34m-win32.whl? There
> > weren't any win32 builds on
> https://pypi.python.org/pypi/recordclass.
>
> It's in the middle
> of the file list:
>
> recordclass-0.4.3-cp34-cp34m-win32.whl (md5) Python Wheel
> cp34 2017-04-17 17KB
Actually, I see now there are several win32.whl files on that page. I'm
not familiar with PyPi's link formatting and I didn't realize that both
the wheel and md5 files were available from each of those links, and I
only clicked on the md5s. (Truth be told I didn't even see the .whls. It
was late, and though I could read and write, I was a little bleary
around the edges.)
> Maybe you're looking at a cached page in your browser? But
> that doesn't explain why pip doesn't see it.
Actually, when I tried "pip install
recordclass-0.4.3-cp34-cp34m-win32.whl" it failed almost immediately
with:
"recordclass-0.4.3-cp34-cp34m-win32.whl is not a supported wheel on this
platform."
The one time I tried "pip install recordclass", it found
0.4.3-cp34-cp34m-win32 alright. It got as far as copying, building and
testing it, but failed in test:
Installing collected packages: recordclass
Running setup.py install for recordclass
Complete output from command C:\Programs\Coding\Anaconda3\python.exe
-c "imp
ort setuptools,
tokenize;__file__='E:\\temp\\pip-build-zhximvpd\\recordclass\\se
tup.py';exec(compile(getattr(tokenize, 'open',
open)(__file__).read().replace('\ r\n', '\n'), __file__, 'exec'))"
install --record E:\temp\pip-r7ky4fv1-record\in stall-record.txt
--single-version-externally-managed --compile:
running install
running build
running build_py
creating build
creating build\lib.win32-3.4
creating build\lib.win32-3.4\recordclass
copying lib\recordclass\record.py -> build\lib.win32-3.4\recordclass
copying lib\recordclass\__init__.py ->
build\lib.win32-3.4\recordclass
creating build\lib.win32-3.4\recordclass\test
copying lib\recordclass\test\test_memoryslots.py ->
build\lib.win32-3.4\reco rdclass\test
copying lib\recordclass\test\test_record.py ->
build\lib.win32-3.4\recordcla ss\test
copying lib\recordclass\test\__init__.py ->
build\lib.win32-3.4\recordclass\ test
running build_ext
building 'recordclass.memoryslots' extension
error: Microsoft Visual C++ 10.0 is required (Unable to find
vcvarsall.bat).
So it choked when it needed Visual C++ to test the installation, at
least that's what I'm assuming it was testing.
It continues to amaze me that Anaconda and Python.org, probably the two
biggest distributors of official Python builds, are now relying on
Visual C++. Why can't Python developers write the entire setup and
installation code in Python? Surely Python has the required
functionality, and it seems more than a little demeaning for Python to
be using Visual C++ as a crutch.
Relatedly, why is Python lacking in the basic build tools for users to
easily build and install packages and full releases from source?
Something for Python (loosely) akin to the earliest versions of Visual
Studio would do the job, and it wouldn't have to be real tricked out.
I've seen this lack show up in several threads on this list, including
my original question in this thread. I was fishing for hints about the
build tools in Python as a way to build recordclass from source, but
apparently there aren't any. Not that advanced users know about anyway.
Is the Python dev team so lacking in resources that they can't cover
this fundamental base? Microsoft had build teams in dev at least as
early as the first release of Windows NT, and probably much earlier. I'd
always assumed that major language developers would establish build and
installation teams very early on. Alhough, Microsoft's setup teams still
really sucked bananas as late as when the the first XP was released in
2001 (don't know anything about them since), but the build teams were
rock stars that everyone looked up to from the get go. Apparently Python
hasn't mirrored that sequence of development steps.
> > Maybe I can find an earlier 3 build that won't demand Visual C++.
>
> The wheel doesn't need a compiler. It has an ABI tag because
> it already includes the compiled extension module.
Ah, and you've got me there. I have no clue what an ABI tag is or why
it's significant, and I don't know a fraction enough about wheels to
know whether they'd use a compiler or not. Grist for the mill, so
thanks.
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
