Installation issues

[JH-FP]

Hi, we're attempting to try out USD, but are running into some issues getting it onto multiple machines, and are not sure how to best proceed.

I don't have Visual Studio myself, so a colleague went through the build (which included Alembic as the only special add in). That all worked successfully on his machine. We then copied the file over to my machine and added the needed environment variables however, something has gone wrong as when I try usdview, I am met with the following:

Looking in the file system, that module is there, so I'm unsure why it's complaining. Does anyone have any ideas what might be going awry here? We're on Win10 Enterprise.

Prehaps copying the built folders over and setting the env variables isn't the best way to deploy a USD build across a number of computers - in which case, can anyone suggest how to proceed? I wasn't able to find anything online about it. It isn't viable to individually build it on every machine, as we don't have site wide VS. Any help greatly appreciated! Thanks very much.

Kind Regards,

Jon

[asluk]

As for the needed env vars, can you print your %PATH% and %PYTHONPATH% here?

See also https://github.com/PixarAnimationStudios/USD/issues/1334 for some other things to check and some ways to track down the missing DLL.

[JH-FP]

Hi, thanks for getting back to me, here are the path read outs:

PATH: C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files\Perforce;C:\WINDOWS\system32;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler;C:\windows\system32\blur64;C:\Program Files (x86)\Common Files\Intel\Shared Files\fortran\bin\ia32;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\compiler;c:\Program Files (x86)\Intel\iCLS Client\;c:\Program Files\Intel\iCLS Client\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files\Common Files\Autodesk Shared\;C:\win32app\ingr\ipshare\bin;C:\Program Files (x86)\Common Files\Autodesk Shared\;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Radiance\bin\;C:\Program Files (x86)\Autodesk\Backburner\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\3Delight\bin;C:\Program Files\Git\cmd;C:\USD\bin;C:\USD\lib;C:\Program Files\VRay\vray_adv_41002_katana3.0_x64\RenderBin;C:\Users\jhudson\AppData\Local\Microsoft\WindowsApps;C:\Python27;C:\Python27\Scripts;C:\Python27\Lib;C:\Program Files\Git\mingw64\bin;C:\Program Files\JetBrains\PyCharm Community Edition 2019.2.3\bin;;C:\Users\jhudson\Miniconda2;C:\Users\jhudson\Miniconda2\Scripts;C:\USD\lib;C:\USD\bin;

PYTHONPATH: C:\Program Files\Laubwerk\Python;\corporate\resources\Application\Thinkbox_Deadline\IToo\Laubwerks\Python;C:\USD\lib\python;

is _ar.pyd not what it's looking to import there and failing? There's two import in the init file, Ar and Tf, if I swap the order of them in that init and run usdview, it says it can't find TF instead, again even though it seems alive and well in my file system!

I can't follow your advice in the other thread as I can't install VS.

[marktucker]

Is there any chance this is a Windows "security" thing where it is refusing to load the .pyd dynamic library because it "came from the internet" (I know, you copied it from a co-worker's machine, but it might matter how you copied it)? This might depend on your Windows domain policies or some such thing that I know nothing about. I just raise this possiblity because it really looks like it should work. Unfortunately I don't know how to test this theory...

[JH-FP]

That sounds plausible, but equally I have no idea how I could test that!

[meshula]

is ar.dll in C:\USD\lib? ar.dll is probably what it's complaining about. It's probably there, so:

A frequent source of confusion is the scope of environment variables in Windows. If you haven't already, I suggest, on the user's machine, try using RapidEnv to set up PATH and PYTHONPATH, rather than using a batch or cmd file. That way the paths will be set up in any command shell.

When debugging this sort of problem, the first thing I do is run dependencies.exe on, in this case, _ar.pyd. This may provide enough breadcrumbs to proceed. https://github.com/lucasg/Dependencies

[vicpon]

I seem to have some dependency issues as well, but this dll seems to be an OS level dll that can't be installed with a service pack or other update?

Command line gives me:

Traceback (most recent call last):
  File "D:\usd\bin\usdview", line 28, in <module>
    import pxr.Usdviewq as Usdviewq
ModuleNotFoundError: No module named 'pxr'

[meshula]

@vicpon Your DLLs do seem to be resolving correctly so your PATH variable is correct.

This message

Traceback (most recent call last):
  File "D:\usd\bin\usdview", line 28, in <module>
    import pxr.Usdviewq as Usdviewq
ModuleNotFoundError: No module named 'pxr'

says that the pxr Python module can't be found, which means the PYTHONPATH does not have the the directory with the pxr tree in it. If you didn't change any options, you should be able to find it in d:\usd\lib\python - if you dir that directory, you should see a pxr folder, and within that, you should see init.py which is the file Python searches for ~ if it can't find that file you get the message you reported. So, your PYTHONPATH should have d:\usd\lib\python in it.

[jilliene]

Filed as internal issue #USD-6420

[vicpon]

@vicpon Your DLLs do seem to be resolving correctly so your PATH variable is correct.

This message

Traceback (most recent call last):
  File "D:\usd\bin\usdview", line 28, in <module>
    import pxr.Usdviewq as Usdviewq
ModuleNotFoundError: No module named 'pxr'

says that the pxr Python module can't be found, which means the PYTHONPATH does not have the the directory with the pxr tree in it. If you didn't change any options, you should be able to find it in d:\usd\lib\python - if you dir that directory, you should see a pxr folder, and within that, you should see init.py which is the file Python searches for ~ if it can't find that file you get the message you reported. So, your PYTHONPATH should have d:\usd\lib\python in it.

Thanks @meshula. Yes, I do have d:\usd\lib\python in my PYTHONPATH. For some reason I don't understand, moving the python installation directory from PYTHONPATH to PATH fixed the issue. It works great now, thank you for the help!

[meshula]

It's probably some witch's brew combination of Python's ..ahem.. unique path resolution algorithms for pads crossed with windows own ...errm.. heuristic methods for dlls. Glad you've sorted it out!

[sunyab]

Closing this out, thanks all!

[JH-FP]

Hi sunyab, this isn't fixed, so can I ask why you're closing it? vicpon's issue might be fixed, but mine isn't!

Using meshula's Dependency check I think it might be that my colleague built with a version of Python I don't have, and I'm awaiting when they have time to rebuild for me for us to test again, but until then I'm afraid this isn't actually solved!

[sunyab]

Oops, my mistake! Reopening.

[JH-FP]

Thanks! I'll report back after the rebuild!

[MightyCreak]

In case someone like me gets here with somewhat the same issue, but not exactly the same output, do try @meshula's advice and install https://github.com/lucasg/Dependencies

I found that NVIDIA's pre-built libraries and tools where using Python 3.6 and needed this exact version. I uninstalled 3.7.4 and installed 3.6.7 and the tools started to work as expected (don't forget to reinstall PySide2 and PyOpenGL as they were installed for another version of Python).

Note: I first tried building the code on Windows, but after a couple of dependency issues I gave up 😞