* add support for parsing and building pure pyproject.toml packages within azure-sdk-tools
* various typing updates across azure-sdk-tools, cleaning up what code paths I'm touching with the new build and parse support
* add tests for various pyproject.toml parse scenarios
* bump setuptools to 74.1.3 to support pure-pyproject.toml extension packages (eg without a setup.py)
---------
Co-authored-by: McCoy Patiño <39780829+mccoyp@users.noreply.github.com>
* 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>
* apply black and prepare for parsing the ci.yml so that we can understand if testproxy is enabled or disabled
* The language specific cert trust in Language-Settings has been updated to no longer globally set environment variables SSL_CERT_DIR, SSL_CERT_FILE, and REQUEST_CA_BUNDLE. These are dynamically set in proxy_startup.py
* encode the fact that azure-eventhub does not support pypy machines
* add azure-sdk-tools test workflow
* update cspell to account for new workflow
* fix matrix generation when no direct packages are present
* fix a test relying on folder ordering to NOT depend on that folder ordering
* refactor package selection methodology to utilize Save-Package-Properties for package targeting
* introduce the python - pullrequest build definition that is triggered against all sdk/ directories, and builds/tests the packages which were changed
* this also includes abstractions to reduce runtime by distributing sets of packages and duplicating matrix definition
* refactor all analyze checks which used to operate on ServiceDirectory to instead operate upon the packages present within a PackageInfoFolder from Save-Package-Properties
* miscellaneous tooling changes to account for new matrix possibilities
---------
Co-authored-by: Wes Haggard <weshaggard@users.noreply.github.com>
Co-authored-by: Patrick Hallisey <pahallis@microsoft.com>
* refactor: Return full Requirements object instead of [name, specifier]
* feat: Filter out requirements that apply to the current environment
* feat: Add a log message when a requirement is skipped
* small update covering a couple extra usages of parse_require
---------
Co-authored-by: Scott Beddall <scbedd@microsoft.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.
* remove a bunch of setuptools pins in favor of the single generic. this is only relevant to setuptools, a greater cleanup along with some CG updates should also be carried out
* make sphinx == strict_sphinx and bump to v7.3
* strict sphinx only on dataplane
* remove issue creator for sphinx, now mandatory in CI
* test that we can still disable if needed
* cleaning up docs and weekly template
* try disable with artifacts
* remove test skip
* pin setuptools to 69.2.0
* use virtualenv for our virtual environment creation instead of default venv
* source the virtual environment just before build steps, versus prepending path which was working unreliably
* remove venv use from test phase, as it wasn't actually having the effect we originally expected
Yuchao Yan
Scott Beddall
kdestin
iscai-msft
McCoy Patiño
Neehar Duvvuri
Xiang Yan
catalinaperalta
Krista Pratico
vincenttran-msft