Python tool install fails due to long pathnames

[elatt]

We've had customer reports (and were able to reproduce locally) but it seems that if a combination of the username and/or tool name is sufficiently long, non-admin users will fail to be able to install Python based tools.

The error they will receive is also very unhelpful:

This is all that is displayed and then you have to click OK, and the tool will have no traces of installation (no the directory will be deleted completely).

We traced this down and it is actually because when Alteryx creates the new conda virtualenv, the first step is to upgrade pip to the latest version and this will fail if the paths are too long: https://github.com/pypa/pip/issues/3055

We were able to reproduce this issue on a Windows 10 machine running as a non-admin user (admin users do not have this issue, even if they install to a long path).

I'm not sure the correct solution for this, in the past I've solved these types of path issues on Windows by using Reparse Points: https://docs.microsoft.com/en-us/windows/desktop/fileio/reparse-points. In the pip bug tracker, there are also discussions about Windows 10 registry settings.

[tlarsen7572]

I think this is the same issue that was posted here.  The symptoms you describe sure match what I have seen.  You have gotten a lot further in tracking down the issue than we have.

My experience corroborates the idea that the paths are too long.  My install fails when I install only for my account, whether or not Alteryx is being run as admin.  If I install for all users, the install succeeds.  My user ID is long, so the path for the user-specific install must be too long as a result.

Would special characters cause an issue?  My user ID on my computer includes dots and @.

[elatt]

Yes, your linked issue almost certainly smells like the same bug. You should be able to reproduce it outside of Alteryx (and then be able to see the full error exception) by creating a virtualenv in the same location that Alteryx would and being sure to run the upgrade pip command.

As far as the special characters goes, I don't think dots and @ should be a problem but I'm not that familiar with all the nuances of Windows paths.

[PaulN]

Hi,

Having faced the issue on a Windows 10 machine, changing the following fixed the issue for me.

1. Open Registry Editor (regedit.exe)

2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

3. Right click on the key and Export for backup

4. Change value LongPathsEnabled from 0 to 1

5. Re-install reluctant YXI again (no restart should be needed).

Thanks,

Paul Noirel

Sr Customer Support Engineer, Alteryx

[elatt]

Yes, this registry setting does work however you need to be an Admin to make changes to the HKEY_LOCAL_MACHINE hive so I will refrain from accepting it as the solution because I feel that defeats the purpose of the Alteryx Non-Admin install.

[PaulN]

Hi @elatt,

That is a fair point.

Thanks, 

Paul Noirel

Sr Customer Support Engineer, Alteryx

[MarkSmith]

I had this same issue.   your edit suggestion worked good for the input tool.

I had an error for the output tool stating:  Cache entry deserialization failed, entry ignored.

[wthompson]

@MarkSmith Atom,

The issue with 'Cache entry deserialization failed, entry ignored' warning being treated as an error in the YXI installer is fixed in the latest release of Alteryx 2018.4.3.54046.  To resolve that issue on previous version of the YXI installer, you need to clear your pip cache directory.

This warning reflects that you have additional versions of Python installed on your system.  Unfortunately, all versions of Python use the same PIP cache directory, so this is likely to occur again.

The shared PIP cache directory is located, on Windows systems, in C:\Users\%USER%\AppData\Local\pip\cache.  So, to resolve the warning, all you need to do is delete the entire pip cache directory.  This will prevent the pip installer from seeing the cache entry that is for a different version of Python and will instead install a new copy of the dependency.

I hope that this fixes your current issue, but please let me know, if it doesn't.

Thanks

[MarkSmith]

Yes, that solved the issue.  Thanks!

[MarkSmith]

I do have another question regarding the Azure Data Lake Input tool:

When setting it up it seems to take my inputs.  It then looks to be asking for the source file path, but the "File path" is grayed out.

Any advice to resolve this?