You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -107,7 +107,7 @@ Mypy install and run.
107
107
```
108
108
109
109
#### `sphinx` environment
110
-
Generate shpinx doc for this package.
110
+
Generate sphinx doc for this package.
111
111
112
112
```
113
113
\> tox -e sphinx -c <path to tox.ini>
@@ -117,7 +117,7 @@ Generate shpinx doc for this package.
117
117
118
118
`tox` supports custom arguments, and the defined pytest environments within the common `tox.ini` also allow these. Essentially, separate the arguments you want passed to `pytest` by a `--` in your tox invocation.
119
119
120
-
[Tox Documentation on Positional Arguments](https://tox.readthedocs.io/en/latest/example/general.html#interactively-passing-positional-arguments)
120
+
[Tox Documentation on Positional Arguments](https://tox.wiki/en/latest/config.html#substitutions-for-positional-arguments-in-commands)
121
121
122
122
**Example: Invoke tox, breaking into the debugger on failure**
Copy file name to clipboardExpand all lines: doc/dev/mgmt/multiapi.md
+4-6Lines changed: 4 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Multi-api packaging and ARM SDK
2
2
3
-
Several SDKs on this repository are able to support multi-api in a single package. If you're a SDK maintener, this documentation explains the rational of it, and the technical details.
3
+
Several SDKs on this repository are able to support multi-api in a single package. If you're a SDK maintainer, this documentation explains the rational of it, and the technical details.
4
4
5
5
## Overview and rationale
6
6
@@ -10,7 +10,7 @@ It means a given specific package is able to do calls to several different API v
10
10
11
11
### Why would I need to call anything else than the latest API version?
12
12
13
-
Because there is different flavors of Azure that are not necessarly provided with the same set of API versions. For example Azure Governement, Azure Stack usually needs a few months to get the latest available API version.
13
+
Because there is different flavors of Azure that are not necessarily provided with the same set of API versions. For example Azure Government, Azure Stack usually needs a few months to get the latest available API version.
14
14
15
15
### Why a multi-api package?
16
16
@@ -66,9 +66,9 @@ Main design guidelines:
66
66
- For people that want a specific API version for a specific need, specifying API version should be possible
67
67
e.g. `client = ComputeManagementClient(credentials, sub_id, api_version='2018-06-01')`
68
68
- For people who target a single Azure Profile, specifying it should be be possible
69
-
e.g. `client = ComputeManagementClient(credentials, sub_id, profile=KnownProfile.v2018_06_01_bybrid)`
69
+
e.g. `client = ComputeManagementClient(credentials, sub_id, profile=KnownProfile.v2018_06_01_hybrid)`
70
70
71
-
The first condition has impact on models loading, by default they should load the latest API vesion transparently:
71
+
The first condition has impact on models loading, by default they should load the latest API version transparently:
72
72
```python
73
73
# Loads the latest version of the model
74
74
from azure.mgmt.compute.models import VirtualMachineCreateParameter
@@ -118,5 +118,3 @@ If this is not the same API version, then we need to bend the rules a little: we
118
118
## Possible improvements
119
119
120
120
Current implementation assumes operation group are unique, and as discussed it's not always the case. Also, this limitation has impact on intellisense right now. Example, if a user types `compute_client.virtual_machines.` and hit the intellisense shortcut, users won't see any suggestions. It's because the `virtual_machines` property is dynamic and can change depending of dynamic configuration.
121
-
122
-
To improve intellisense and allow operation level profile, the concept would be to make the [operation mixin multi-api concept](https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/network/azure-mgmt-network/azure/mgmt/network/_operations_mixin.py) applicable to operation groups as well. I estimate this work to a week of dev-ish.
Many of our test suites use a mixin class to reduce re-writing code in multiple test files. For example, in the Tables test suite there is a `_shared` directory containing two of these mixin classes, a [sync one](https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/tables/azure-data-tables/tests/_shared/testcase.py) and an [async version](https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/tables/azure-data-tables/tests/_shared/asynctestcase.py). These classes will often have ways to create connection strings from an account name and key, formulate the account url, configure logging, or validate service responses. In order for these mixin classes to be used by both the functional and unit tests they should inherit from `object`. For example:
@@ -74,8 +77,8 @@ class TestTablesUnit(TablesTestMixin):
The Azure SDK team has created some in house tools to help with easier testing. These additional tools are located in the `devtools_testutils` package that was installed with your `dev_requirements.txt`. In this package are the preparers that will be commonly used throughout the repository to test various resources. A preparer is a way to programmatically create fresh resources to run our tests against and then deleting them after running a test suite. These help guarantee standardized behavior by starting each test group from a fresh resource and account.
80
83
81
84
If this situation is a requirement for your tests, you can opt to create a new preparer for your service from the management plane library for a service. There are already a few preparers built in the [devtools_testutils](https://github.com/Azure/azure-sdk-for-python/tree/main/tools/azure-sdk-tools/devtools_testutils). Most prepares will start with the [`ResourceGroupPreparer`](https://github.com/Azure/azure-sdk-for-python/blob/main/tools/azure-sdk-tools/devtools_testutils/resource_testcase.py#L29-L99) to first create a resource group for your service.
@@ -86,8 +89,6 @@ To build your own preparer you will need to use the management plane library to
86
89
|-|-|-|
87
90
| Resource Group |[link](https://github.com/Azure/azure-sdk-for-python/blob/main/tools/azure-sdk-tools/devtools_testutils/resource_testcase.py#L57-L85)|[link](https://github.com/Azure/azure-sdk-for-python/blob/main/tools/azure-sdk-tools/devtools_testutils/resource_testcase.py#L87-L99)|
We’re retiring the Azure Video Analyzer preview service; you're advised to transition your applications off of Video Analyzer by 01 December 2022. This SDK is no longer maintained and won’t work after the service is retired. To learn how to transition off, please refer to: [Transition from Azure Video Analyzer - Azure Video Analyzer | Microsoft Docs](https://docs.microsoft.com/azure/azure-video-analyzer/video-analyzer-docs/transition-from-video-analyzer)
3
+
We’re retiring the Azure Video Analyzer preview service; you're advised to transition your applications off of Video Analyzer by 01 December 2022. This SDK is no longer maintained and won’t work after the service is retired. To learn how to transition off, please refer to: [Transition from Azure Video Analyzer - Azure Video Analyzer | Archived Microsoft Docs](https://github.com/MicrosoftDocs/azure-docs/blob/4ba87bedc7b17a32903c99afb3ca4163be0dcc90/articles/azure-video-analyzer/video-analyzer-docs/transition-from-video-analyzer.md)
4
4
5
5
The complete list of available packages can be found at: https://aka.ms/azsdk/python/all
0 commit comments