* during mindependency runs, dev_requirements on local relative paths are now checked for conflict with the targeted set of minimum dependencies
* multiple type clarifications within azure-sdk-tools
* added tests for new conflict resolution logic
---------
Co-authored-by: McCoy Patiño <39780829+mccoyp@users.noreply.github.com>
python_requires must follow the specification defined in:
https://packaging.python.org/en/latest/specifications/version-specifiers/#id5
In the event that a package version specifies a `python_requires`
that does not match that spec, execution terminates with
an InvalidSpecifier exception.
This commit makes it so that we catch and log the exception,
ignoring the version that has the invalid python version specifier.
An alternative solution could have been to attempt to correct
the version specifier (e.g. '>= 3.5.*' is invalid, but it'd be
trivial to correct it to '>=3.5'). But that would potentially invite
a complexity that costs more than it's worth.
* Moves the analyze_deps script into azure-sdk-tools as an entrypoint 'sdk_analyze_deps' and add typing information to definition file
* Updates the analyze_dependencies module to evaluate the dependency specifiers found across the repo. If any combination of specifiers eliminates all available versions from PyPI (combined with local if present) we will throw. This won't catch transitive dependencies, but it will definitely catch conflicts in directs. A follow-up PR enabling poetry will validate transitive deps.
* Updates our shared_requirements.txt to more of a known dependencies list. It is now more of a "Yes we do have an external dep on isodate. None of the specifiers cause conflicts though."
* remove requests dependency from PyPIClient in favor of urllib3
* update tox packaging dependency with urllib3
* add urllib3 to azure-sdk-tools requirements
* SDK-Tools refactor
* Refactors scripts present under eng/versioning to namespace ci_tools.versioning within the azure-sdk-tools package. All Integration points in CI are flipped over to consume entrypoints defined in the setup.py.
* Refactors build_packages.py and build_package.py into single module ci_tools.build. This function create_package within this module is used wherever packages are built.
* Moves anything related to setup.py parsing into ci_tools.parsing. More specifically, allows users access to ParsedSetup which has a classmethod from_path that can be aimed at any setup.py or package root.
* Instead of a crazy tuple that we can get lost in the sauce in, it's just strongly typed members of a class now.
* Moves anything related to processing of requirements into ci_tools.functions.
* Type and doc comment all the moved common functionality
Scott Beddall
kdestin
Neehar Duvvuri
catalinaperalta
Sean Kane
Charles Lowell
praveenkuttappan