Mitigate the pylint error caused by setuptools

[troydai]

Since 12/12/2016, the CI build on python 3.5-dev began failing while running pylint. The errors are import-error. The error was caused by setuptools. The python 3.5-dev build uses the latest setuptools. A change introduced between 30.4.0 and 31.0.0 add additional .pth file to the installation folder under virtualenv. The files obviously confused the pylint cause import-error in turn.

This change will fix the setuptools version to 30.4.0 to mitigate this issue.

[tjprescott]

LGTM. Should probably have Derek weigh in as well.

[troydai]

Thank you. I just added @derekbekoe to the reviewers list as well.

[tjprescott]

Even with the older version of setuptools, I'm still getting this import-error behavior with pylint on Python 3.5, but 2.7 works.

[troydai]

Respond to @tjprescott last comment. More people may hit this.

To fix the environment your need to:

1. Deactivate the current virtual environment;
2. Clean up the virtual environment folder, by default, it is the env folder;
3. Set up a new virtual environment and enter it;
4. Run dev_setup.py so that the fix will work.

[derekbekoe]

@tjprescott There was a reason we has the install of requirements last.
It was to prevent command modules that are installed later from overriding what we have in requirements.txt.
It was with azure-mgmt-keyvault back when we were using the azure rollup package.

@troydai Is this particular change required for this fix to work?

[derekbekoe]

Since the PR has already been merged, I'm just bringing this to attention.

[tjprescott]

@derekbekoe it was required because otherwise it installs the newest setuptools, screws everything up, and then installs the desired setuptools. However, it seems that KeyVault no longer breaks even with this change.

[troydai]

Ok then, so I can move the requirement.txt restore back to the bottom but specifically install setuptools==30.4.0 at the beginning, does it sound good?

[derekbekoe]

Since we don't have the keyvault problem anymore, I have no issue with it as is. :)

[tjprescott]

I think we no longer have the problem because we now depend on the individual packages. IIRC, the problem originated because we had modules depending on the roll-up package, which would replace the version of KV management that it needed with an older version.