Azure SDK is over 500 MB and growing on each release

https://github.com/Azure/azure-sdk-for-python/issues/17801

Additional update: we have all agreed, including CLI team members, that SDK should stop shipping multi-api SDK entirely. A SDK will target the last known API version as the expected contract. It will still be possible to pass an api_version parameter, but the SDK will not verify if the parameter set passed is conformed to that API version and will let server signal any troubles with a server exception. It's recommended for people that rely on a very specific API version, to pin the SDK package to the version where that API version was the last one (so you get proper typing help at least).

We're rolling this on all packages over the next couple of months.

Part of this effort, we will also split some packages into sub packages. For instance, disks from the azure-mgmt-compute package will have its own individual package. The rational is that disks never versioned its service with the same API versions than regular compute operations (like VM), making that package complex to version, as it actually contained a combination of API versions of various resource types. The bad side effect, is that it will be a breaking change when disks will disappear from azure-mgmt-compute, but the good side effect is even smaller SDK (less API versions and less resource types, both contributing) and a more consistent API version timeline (a unique one per package). The breaking change should be minimal (install new package, and create new client, everything else is still the same, no operation or model change).

We will do this split on a few packages, the exact list is TBD, but if you're aware of a SDK with a mix of various API versions, he's probably on the future list.

Reacted by Benjamin Kane, Orgad Shaneh, Olav Rønnestad Birkeland, Yuchao Yan, Dave Piché and Ivan Chernukha

Reacted by Benjamin Kane, Ross Bender, iscai-msft, Yuchao Yan, Dave Piché, Jonas Lundholm Bertelsen, Jason Frey and TeamDman

{
  "by": "varun_chopra",
  "descendants": 3,
  "id": 40245553,
  "kids": [
    40245593,
    40247401,
    40245639
  ],
  "score": 4,
  "time": 1714726390,
  "title": "Azure SDK is over 500 MB and growing on each release",
  "type": "story",
  "url": "https://github.com/Azure/azure-sdk-for-python/issues/17801"
}

{
  "author": "sodul",
  "date": "2021-04-05T19:07:06.000Z",
  "description": "The azure SDK is ridiculously large for reasons that I have a hard time understanding. We pip install it for our CI pipelines and the vast majority of the size of our container is coming from the A…",
  "image": "https://opengraph.githubassets.com/02ba6db29e59ca6638116dd20273e8338613df56093132ac4ee2db5208801a38/Azure/azure-sdk-for-python/issues/17801",
  "logo": null,
  "publisher": "GitHub",
  "title": "Azure SDK is over 500MB and growing on each release. · Issue #17801 · Azure/azure-sdk-for-python",
  "url": "https://github.com/Azure/azure-sdk-for-python/issues/17801"
}

{
  "url": "https://github.com/Azure/azure-sdk-for-python/issues/17801",
  "title": "Azure SDK is over 500MB and growing on each release. · Issue #17801 · Azure/azure-sdk-for-python",
  "description": "The azure SDK is ridiculously large for reasons that I have a hard time understanding. We pip install it for our CI pipelines and the vast majority of the size of our container is coming from the A...",
  "links": [
    "https://github.com/Azure/azure-sdk-for-python/issues/17801"
  ],
  "image": "https://opengraph.githubassets.com/02ba6db29e59ca6638116dd20273e8338613df56093132ac4ee2db5208801a38/Azure/azure-sdk-for-python/issues/17801",
  "content": "<div><p>Additional update: we have all agreed, including CLI team members, that SDK should stop shipping multi-api SDK entirely. A SDK will target the last known API version as the expected contract. It will still be possible to pass an <code>api_version</code> parameter, but the SDK will not verify if the parameter set passed is conformed to that API version and will let server signal any troubles with a server exception. It's recommended for people that rely on a very specific API version, to pin the SDK package to the version where that API version was the last one (so you get proper typing help at least).</p>\n<p>We're rolling this on all packages over the next couple of months.</p>\n<p>Part of this effort, we will also split some packages into sub packages. For instance, <code>disks</code> from the <code>azure-mgmt-compute</code> package will have its own individual package. The rational is that <code>disks</code> never versioned its service with the same API versions than regular compute operations (like VM), making that package complex to version, as it actually contained a combination of API versions of various resource types. The bad side effect, is that it will be a breaking change when <code>disks</code> will disappear from <code>azure-mgmt-compute</code>, but the good side effect is even smaller SDK (less API versions and less resource types, both contributing) and a more consistent API version timeline (a unique one per package). The breaking change should be minimal (install new package, and create new client, everything else is still the same, no operation or model change).</p>\n<p>We will do this split on a few packages, the exact list is TBD, but if you're aware of a SDK with a mix of various API versions, he's probably on the future list.</p></div><div><p><span>Reacted by Benjamin Kane, Orgad Shaneh, Olav Rønnestad Birkeland, Yuchao Yan, Dave Piché and Ivan Chernukha</span></p><p><span>Reacted by Benjamin Kane, Ross Bender, iscai-msft, Yuchao Yan, Dave Piché, Jonas Lundholm Bertelsen, Jason Frey and TeamDman</span></p></div>",
  "author": "",
  "favicon": "https://github.githubassets.com/favicons/favicon.svg",
  "source": "github.com",
  "published": "2021-04-05t19:07:06z",
  "ttr": 64,
  "type": "object"
}