Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Can't get lxml and etree working

Help
2011-01-17
2013-01-25
  • Pat LaCosse
    Pat LaCosse
    2011-01-17

    I have been running into trouble trying to install libxml2, lxml, etc. for use in PythonScript. I'm on Windows Vista. I added a site-packages directory to plugins/PythonScript/lib and copied over all the subdirectories related to these packages from my regular install of Python.

    Statement from lxml import etree is raising ImportError: DLL load failed: The specified module could not be found.

    The regular install of lxml puts the dlls into site-packages/libxmlmods. I've tried moving those dlls to various directories within PythonScript and Notepad++. Nothing seems to be working. Any guidance?

    Thanks.

     
  • Apologies for the delay in response - I think the emails must have stopped.

    Which version are you using? 0.7 or 0.8?  0.7 uses a standard Python compiled with /MD, ie. the MSVC runtime as DLLs, 0.8 uses Python compiled with /MT, therefore all libraries must also be compiled with /MT.  I'm working on a new version that has better support for Python modules, but the modules still have to be compiled with /MT.  This can obviously be tricky for 3rd party modules - it's hard enough to compile the standard modules with /MT. 

    I'm tempted to have two options, a "standard" release with /MT, that will suit most people, won't require the MS runtime, but won't support 3rd party modules compiled "normally", and another version that requires the MS runtime, but works with 3rd party modules… 

    Thoughts?  

    Dave

     
  • Pat LaCosse
    Pat LaCosse
    2011-02-04

    Thanks for the response.

    I am using 0.8. I started out with 0.7 but upgraded after I was having some problems with callbacks. I believe I attempted to get lxml working in 0.7 too without success, but I can't remember what all I tried.

    I understand the differences you're describing with the compiler, but I don't personally have a lot of experience in that area. I can see the advantages and drawbacks to either approach. My gut reaction is to avoid two different versions if at all possible.

    If both options were equal in terms of implementation and maintainability, I'd prefer the ability to extend Python with 3rd party modules. Don't get me wrong, what you've already done is just awesome, and I've lived without any Python in Notepad++ for years. But once I found out about Python Script of course I began to think of all the ways I could use it in my daily work, which involves a lot with lxml (and pywin32, pysvn, PIL).

    I'm sure there are other reasons why you might prefer to continue on a trajectory that uses /MT instead. If so, then if a new version included the libxml2/libxslt2/lxml stuff, then you would have at least one very happy user. :-)