Construyendo lxml para Python 2.7 en Windows

Estoy intentando comstackr lxml para Python 2.7 en una máquina con Windows de 64 bits. No pude encontrar lxml egg para Python versión 2.7. Así que lo estoy comstackndo de fonts. Estoy siguiendo las instrucciones en este sitio

http://lxml.de/build.html

bajo la sección de enlace estático. Me estoy equivocando

C:\Documents and Settings\Administrator\Desktop\lxmlpackage\lxml-2.2.6\lxml-2.2. 6>python setup.py bdist_wininst --static Building lxml version 2.2.6. NOTE: Trying to build without Cython, pre-generated 'src/lxml/lxml.etree.c' need s to be available. ERROR: 'xslt-config' is not recognized as an internal or external command, operable program or batch file. ** make sure the development packages of libxml2 and libxslt are installed ** Using build configuration of libxslt Building against libxml2/libxslt in one of the following directories: ..\libxml2-2.7.6--win32--w2k--x64\lib ..\libxslt-1.1.26--win32--w2k--x64--0002\lib ..\zlib-1.2.4--win32--w2k--x64 ..\iconv-1.9.1--win32--w2k--x64-0001\lib running bdist_wininst running build running build_py running build_ext building 'lxml.etree' extension error: Unable to find vcvarsall.bat 

¿Puede alguien ayudarme con esto? Intenté establecer la ruta para tener Microsoft Visual Studio … Puedo ejecutar vcvarsall.bat desde la línea de comandos … pero Python está teniendo problemas

Apuesto a que no estás usando VS 2008 para esto 🙂

Hay def find_vcvarsall (version): function (adivina qué, busca vcvarsall.bat) en los nombres con el siguiente comentario

Al principio trata de encontrar el productdir de VS 2008 en el registro. Si eso falla, se recurre a la var.

Si no está utilizando VS 2008, entonces no tiene ni la clave de registro ni la variable de entorno adecuada y es por eso que distutils no puede encontrar el archivo vcvarsall.bat. No comprueba si se puede acceder al archivo bat a través de la variable de entorno PATH.

La solución es definir la variable VS90COMNTOOLS para que apunte al directorio Herramientas de Visual Studio.

Dicho esto echar un vistazo a 11.4. distutils.msvccompiler – sección del comstackdor de Microsoft en los documentos de Python que indica

Normalmente, los módulos de extensión deben comstackrse con el mismo comstackdor que se utilizó para comstackr Python.

Martin v. Loewis en el correo electrónico titulado Descargar Visual Studio Express 2008 ahora en la lista de correo de la lista de pitones dice lo mismo

Python 2.6, 2.7 y 3.1 están todos construidos con esa versión (es decir, 2008). Debido a otra larga tradición, los módulos de extensión de Python deben construirse con la misma versión del comstackdor (más específicamente, la versión CRT) que Python. Por lo tanto, para crear módulos de extensión para cualquiera de estas versiones, debe tener una copia de VS 2008 o VS 2008 Express.

A la luz de las declaraciones anteriores, debe usar VS 2008 si desea comstackr lxml para Python 2.7, por lo que aunque la configuración VS90COMNTOOLS se encarga de encontrar el archivo vcvarsall.bat, no es la solución.

Dicho esto 🙂 la gente intenta usar un CRT más antiguo con un comstackdor más nuevo:
¿Puedo usar el comstackdor de C ++ de Visual Studio 2010 con la biblioteca en tiempo de ejecución de C ++ de Visual Studio 2008?
¿Cómo hacer que el comstackdor de C ++ use una versión específica de CRT?
VS 2008 – Enlace contra el tiempo de ejecución de C más viejo

Me gustaría agradecer a Kev Dwyer (por señalar la importancia de la versión de VS que se usa) y Stefan Behnel (por señalarme los diálogos como un lugar que se ocupa de la configuración del comstackdor) en el subproceso Problem building lxml en Windows – error: No se puede para encontrar vcvarsall.bat en la lista de correo lxml. También me gustaría agradecer a agronholm del canal IRC freenode #distutils por la confirmación de que distutils contiene código que busca el archivo vcvarsall.bat.

Después de seguir la solución recomendada:

  1. descargando VCForPython27.msi de Microsoft,
  2. instalándolo (Win7, Python (x, y) 2.7.9 32 bits),
  3. ingresar / actualizar la variable de entorno VS90COMNTOOLS al valor del directorio de instalación (C: \ Archivos de progtwig (x86) \ Archivos comunes \ Microsoft \ Visual C ++ para Python \ 9.0)

mi problema todavía existía (quiero construir una extensión de Python en C).

Tuve que hacer los siguientes 2 ajustes increíblemente sucios, antes de que todo funcione.

  1. modifique “msvc9compiler.py” en “C: \ Python27 \ Lib \ distutils” , función find_vcvarsall , para que apunte ahora a “Visual C ++ para Python” en lugar de a “VC” .
  2. copie los directorios del fundador en “C: \ Archivos de progtwig (x86) \ Archivos comunes \ Microsoft \ Visual C ++ para Python \ 9.0 \” a “C: \ Archivos de progtwig (x86) \ Archivos comunes \ Microsoft \ Visual C ++ para Python \” (Es decir, un nivel dir hasta).

No puedo decir quién estaba haciendo algo mal aquí, probablemente yo.

EDITAR. Mover directorios funciona debido al problema descrito en este error de distribución .

incluso si VS90COMNTOOLS está configurado, msvc9compiler no puede encontrar vcvarsall.bat porque está instalado en %installdir%/vcvarsall.bat y no en %installdir%/VC/vcvarsall.bat

La solución descrita está utilizando el símbolo del sistema de Visual C ++:

  1. Ingrese MSVC para el símbolo del sistema de Python

  2. SET DISTUTILS_USE_SDK = 1

  3. SET MSSdk = 1

  4. python.exe setup.py …

Jorj McKie fue casi correcto: de hecho, la instalación de VCForPython27.msi no es suficiente, y sí, hay un problema en los distritos que impiden que encuentre find_vcvarsall. De hecho, el problema no está directamente en los detalles, sino en cómo se empaquetó VCForPython27.msi y dónde se coloca vcvarsall.bat (el diseño de las carpetas es diferente del SDK de VS2008).

Una solución simple mientras tanto, esto se repara en Python 2.7.11: use setuptools en lugar de distutils.

Otra solución manual si estás atascado con distutils:

 1) Enter MSVC for Python command prompt 2) SET DISTUTILS_USE_SDK=1 3) SET MSSdk=1 4) you can then build your C extensions: python.exe setup.py ... 

Informe de errores y solución por Gregory Szorc: http://bugs.python.org/issue23246

Más información y una solución alternativa para usar %% cython magic en IPython: https://github.com/cython/cython/wiki/CythonExtensionsOnWindows

https://github.com/develersrl/gccwinbinaries

Tuve problemas similares. Esto funcionó instantáneamente sin nada más que usar un asistente de instalación y establecer una preferencia.