fix: Distutils removal

[jmahlik]

Closes #4534 #3028

Issue #, if available: #4534

Description of changes: Remove runtime dependency on setuptools. Remove reliance on deprecated distutils.

Testing done: Unit, these functions are drop in replacements now that dirs_exist_ok is a parameter in shutil.copytree.

Merge Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your pull request.

General

• [x] I have read the CONTRIBUTING doc
• [x] I certify that the changes I am introducing will be backward compatible, and I have discussed concerns about this, if any, with the Python SDK team
• [x] I used the commit message format described in CONTRIBUTING
• [x] I have passed the region in to all S3 and STS clients that I've initialized as part of this change.
• [x] I have updated any necessary documentation, including READMEs and API docs (if appropriate)

Tests

• [x] I have added tests that prove my fix is effective or that my feature works (if appropriate)
• [x] I have added unit and/or integration tests as appropriate to ensure backward compatibility of the changes
• [x] I have checked that my tests are not configured for a specific region or account (if appropriate)
• [x] I have used unique_name_from_base to create resource names in integ tests (if appropriate)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 87.37%. Comparing base (d444b7b) to head (e9e08a3).

:exclamation: Current head e9e08a3 differs from pull request most recent head bfb49a2

Please upload reports for the commit bfb49a2 to get more accurate results.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4544      +/-   ##
==========================================
+ Coverage   86.70%   87.37%   +0.67%     
==========================================
  Files         409      389      -20     
  Lines       39067    36773    -2294     
==========================================
- Hits        33872    32132    -1740     
+ Misses       5195     4641     -554     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[sagemaker-bot]

AWS CodeBuild CI Report

• CodeBuild project: sagemaker-python-sdk-pr
• Commit ID: e9e08a30cb42d4b2d7299c1c4b42d680a8c78110
• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[jmahlik]

It looks like there are tests still running on python 3.7. I'm not sure how sagemaker is able to be installed/functions in a 3.7 miniconda environment but it's not supported. Seems like the job runner needs an update since 3.7 has been end of life since June 2023.

The errors come from this env:

/miniconda3/lib/python3.7/site-packages/sagemaker_training/process.py

[jmahlik]

Just let me know if I need to rebase once the python 3.7 issue is taken care of.

[knikure]

@jmahlik Kindly take a look at the failing integ-tests.

[jmahlik]

@jmahlik Kindly take a look at the failing integ-tests.

They are failing from a python 3.7 environment slipping into the test suite. shutil.copytree added the dirs_exist_ok=True parameter added in python 3.8. So it fails on 3.7.

All of them have a similar traceback. I believe this can be traced to the pytorch framework version being out of date, so the image has python 3.7 installed. It doesn't appear pytorch 1.5 is supported on the images page.

@knikure Would it be ok to bump the tests to use 2.1.2 so they are run on a supported python version? I'm not so familiar with the support policy for framework images and couldn't find firm docs on what exactly is supported by the sdk for training. One might imagine with an unsupported python, the image becomes obsolete.

Traceback:

ClientError: AlgorithmError: framework error:
Traceback (most recent call last):
  File "/miniconda3/lib/python3.7/site-packages/sagemaker_containers/_trainer.py", line 84, in train
    entrypoint()
  File "/miniconda3/lib/python3.7/site-packages/sagemaker_sklearn_container/training.py", line 39, in main
    train(environment.Environment())
  File "/miniconda3/lib/python3.7/site-packages/sagemaker_sklearn_container/training.py", line 35, in train
    runner_type=runner.ProcessRunnerType)
  File "/miniconda3/lib/python3.7/site-packages/sagemaker_training/entry_point.py", line 100, in run
    wait, capture_error
  File "/miniconda3/lib/python3.7/site-packages/sagemaker_training/process.py", line 291, in run
    cwd=environment.code_dir,
  File "/miniconda3/lib/python3.7/site-packages/sagemaker_training/process.py", line 208, in check_error
    info=extra_info,
sagemaker_training.errors.ExecuteUserScriptError: ExecuteUserScriptError:
ExitCode 1
ErrorMessage ""
Command "/bin/sh -c ./_repack_script_launcher.sh --dependencies . Retrying..

Framework example for a failing test: https://github.com/aws/sagemaker-python-sdk/blob/55822f780979c589f8549eb20dd8c1da80aa7f7a/tests/integ/sagemaker/workflow/test_retry.py#L166-L174

[benieric]

Hello, can you please check on the failing integ? For some reason, I do not see the retry button to retrigger your tests, so if you could push a dummy commit or reset head, re-commit, and force push to trigger tests again we can work on getting this merged

[jmahlik]

Hello, can you please check on the failing integ? For some reason, I do not see the retry button to retrigger your tests, so if you could push a dummy commit or reset head, re-commit, and force push to trigger tests again we can work on getting this merged

@benieric I just force pushed. The torch integration tests will still fail. The image used in those tests is outdated and on an unsupported python version (3.7). I'm wondering if it's acceptable to bump this in the tests. This could break code that is doing the model repacking on unsupported python versions.

I'm not sure what the support policy is for these framework versions so left it as is for the time being. Happy to updated it but wanted a maintainer to make the call on that aspect.

If the images on unsupported python versions need to continue being supported, an alternative might be re-implementing shutil.copytree(source, destination, dirs_exist_ok=True) directly in the codebase.

Just let me know what y'all prefer.

https://github.com/aws/sagemaker-python-sdk/blob/d444b7bb0351c4e74545fb378aed70da14d40483/tests/integ/sagemaker/workflow/test_retry.py#L166-L174

[benieric]

Hello, can you please check on the failing integ? For some reason, I do not see the retry button to retrigger your tests, so if you could push a dummy commit or reset head, re-commit, and force push to trigger tests again we can work on getting this merged

@benieric I just force pushed. The torch integration tests will still fail. The image used in those tests is outdated and on an unsupported python version (3.7). I'm wondering if it's acceptable to bump this in the tests. This could break code that is doing the model repacking on unsupported python versions.

I'm not sure what the support policy is for these framework versions so left it as is for the time being. Happy to updated it but wanted a maintainer to make the call on that aspect.

If the images on unsupported python versions need to continue being supported, an alternative might be re-implementing shutil.copytree(source, destination, dirs_exist_ok=True) directly in the codebase.

Just let me know what y'all prefer.

https://github.com/aws/sagemaker-python-sdk/blob/d444b7bb0351c4e74545fb378aed70da14d40483/tests/integ/sagemaker/workflow/test_retry.py#L166-L174

Good point, I think we may need to explicitly deprecate support for py3.7 from the SDK itself before bumping this

[jmahlik]

It doesn't seem that 3.7 is supported by the sdk at all. https://github.com/aws/sagemaker-python-sdk/blob/d444b7bb0351c4e74545fb378aed70da14d40483/setup.py#L119. It won't pip install on 3.7 without hack arounds. 3.7 got removed in https://github.com/aws/sagemaker-python-sdk/commit/498d94d340bb1bf5b1babde15e86c7b1ad755282. Some of the framework versions were bumped in that commit.

This is a weird case where it looks like the sdk uploads itself as files and runs that repacking code. But the python inside the older framework images is still on 3.7.

[benieric]

Hello, can you please check on the failing integ? For some reason, I do not see the retry button to retrigger your tests, so if you could push a dummy commit or reset head, re-commit, and force push to trigger tests again we can work on getting this merged

@benieric I just force pushed. The torch integration tests will still fail. The image used in those tests is outdated and on an unsupported python version (3.7). I'm wondering if it's acceptable to bump this in the tests. This could break code that is doing the model repacking on unsupported python versions.

I'm not sure what the support policy is for these framework versions so left it as is for the time being. Happy to updated it but wanted a maintainer to make the call on that aspect.

If the images on unsupported python versions need to continue being supported, an alternative might be re-implementing shutil.copytree(source, destination, dirs_exist_ok=True) directly in the codebase.

Just let me know what y'all prefer.

https://github.com/aws/sagemaker-python-sdk/blob/d444b7bb0351c4e74545fb378aed70da14d40483/tests/integ/sagemaker/workflow/test_retry.py#L166-L174

Hey, it is better if we can check that these work on all the latest images without hardcoding. The pytorch image version being used in the image is old (https://github.com/aws/sagemaker-python-sdk/blob/e09693cf115b37259ded02975b4b0bcf88deb0e0/src/sagemaker/image_uri_config/pytorch.json#L1391)

[jmahlik]

I can take a look at implementing something to load the json and pick the max version for the test cases if that's what you were thinking?

[benieric]

I can take a look at implementing something to load the json and pick the max version for the test cases if that's what you were thinking?

Take a look at the test_pytorch.py. There are some pytorch_training_latest_version and pytorch_inference_latest_version fixtures that you can probably reuse

[sage-maker]

Hello, do you require any support on this PR?

[jmahlik]

Hello, do you require any support on this PR?

I'd very much appreciate if someone were to pick it up :). I haven't had time unfortunately. It's from an org repo so you won't be able to push directly, but feel free to apply the diff on a different branch so the changes can get through.

[sage-maker]

@jmahlik I think I can pick it up, but can you provide a high-level overview of what you mean by "load the json and pick the max version"? To my understanding the only thing that needs fixing here is the PyTorch version?

[jmahlik]

Essentially, it should be tested against the latest pytorch version. The versions are kept in a json file. It looks like there are some fixtures that can be used to get the latest version vs. Loading the file manually.

Take a look at the test_pytorch.py. There are some pytorch_training_latest_version and pytorch_inference_latest_version fixtures that you can probably reuse