Azure SDK is over 500MB and growing on each release.

[sodul]

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 Azure SDK, in the SDK the network directory is taking almost half of the size and this is because there are 39 versions of the SDK.

I have never seen anyone doing such a strange approach to version their API clients. I fail to understand why anyone would even want to use the client from 2015 on a cloud product like Azure.

root@1bba10bd1500:~/.pyenv/versions/3.9.2/lib/python3.9/site-packages/azure/mgmt/network# du -shc * | grep M | sort -n 
1.2M	aio
2.4M	v2015_06_15
3.3M	v2016_09_01
3.5M	v2016_12_01
3.7M	v2017_03_01
4.4M	v2017_06_01
4.4M	v2017_08_01
4.9M	v2017_09_01
5.1M	v2017_10_01
5.1M	v2017_11_01
5.1M	v2018_01_01
5.7M	v2018_02_01
6.5M	v2018_04_01
6.6M	v2018_06_01
6.9M	v2018_07_01
8.3M	v2018_08_01
8.4M	v2018_10_01
8.6M	v2018_11_01
8.8M	v2018_12_01
9.0M	v2019_02_01
9.5M	v2019_04_01
10M	v2019_06_01
11M	v2019_07_01
11M	v2019_08_01
11M	v2019_09_01
11M	v2019_11_01
11M	v2019_12_01
12M	v2020_03_01
12M	v2020_04_01
13M	v2020_05_01
13M	v2020_06_01
13M	v2020_07_01
13M	v2020_08_01
259M	total

Can the default release only prove the latest version of the client libraries, or at least provide a 'lean' version of the SDK? This release model is certainly not sustainable and is causing useless grief to your users.

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @aznetsuppgithub.

Issue Details

---

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 Azure SDK, in the SDK the network directory is taking almost half of the size and this is because there are 39 versions of the SDK.

I have never seen anyone doing such a strange approach to version their API clients. I fail to understand why anyone would even want to use the client from 2015 on a cloud product like Azure.

root@1bba10bd1500:~/.pyenv/versions/3.9.2/lib/python3.9/site-packages/azure/mgmt/network# du -shc * | grep M | sort -n 
1.2M	aio
2.4M	v2015_06_15
3.3M	v2016_09_01
3.5M	v2016_12_01
3.7M	v2017_03_01
4.4M	v2017_06_01
4.4M	v2017_08_01
4.9M	v2017_09_01
5.1M	v2017_10_01
5.1M	v2017_11_01
5.1M	v2018_01_01
5.7M	v2018_02_01
6.5M	v2018_04_01
6.6M	v2018_06_01
6.9M	v2018_07_01
8.3M	v2018_08_01
8.4M	v2018_10_01
8.6M	v2018_11_01
8.8M	v2018_12_01
9.0M	v2019_02_01
9.5M	v2019_04_01
10M	v2019_06_01
11M	v2019_07_01
11M	v2019_08_01
11M	v2019_09_01
11M	v2019_11_01
11M	v2019_12_01
12M	v2020_03_01
12M	v2020_04_01
13M	v2020_05_01
13M	v2020_06_01
13M	v2020_07_01
13M	v2020_08_01
259M	total

Can the default release only prove the latest version of the client libraries, or at least provide a 'lean' version of the SDK? This release model is certainly not sustainable and is causing useless grief to your users.

Author:	sodul
Assignees:	-
Labels:	Mgmt, Network, Service Attention, customer-reported, question
Milestone:	-

[kristapratico]

Hi @sodul, thanks for the feedback, we'll investigate asap.

[jiasli]

Previously reported in #11149.

[sodul]

To clarify #11149 is only about azure-mgmt-network which is the largest directory but the problem is present across the entire Azure SDK.

I understand the reasoning for the approach to keep everything for backward compatibility but if you do have customers that point to the old versions then they should pin their requirement versions to the old pypi.org releases of the Azure SDK, not force everyone to keep a copy of everything around. How about providing two versions of the SDKs: one large with everything, one small with just the latest version.

[nolaexe]

Hey, is there any update?

[sodul]

I wrote a script that we run after pip install. It detects the unused versions and this got us an azure folder shrink from ~ 680MB to ~ 280MB. It cannot go any lower because for some reason some of the objects model definitions from multiple versions are merged together to make the final list that is then used. The script detects the versions that are used internally by the SDK and preserves them, making the script very safe to use.

If there is interest I can open source the script.