Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Distutils removal #4544

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

jmahlik
Copy link
Contributor

@jmahlik jmahlik commented Mar 27, 2024

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

  • I have read the CONTRIBUTING doc
  • 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
  • I used the commit message format described in CONTRIBUTING
  • I have passed the region in to all S3 and STS clients that I've initialized as part of this change.
  • I have updated any necessary documentation, including READMEs and API docs (if appropriate)

Tests

  • I have added tests that prove my fix is effective or that my feature works (if appropriate)
  • I have added unit and/or integration tests as appropriate to ensure backward compatibility of the changes
  • I have checked that my tests are not configured for a specific region or account (if appropriate)
  • 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.

@jmahlik jmahlik requested a review from a team as a code owner March 27, 2024 18:20
@jmahlik jmahlik requested review from mufaddal-rohawala and removed request for a team March 27, 2024 18:20
@@ -173,7 +172,7 @@ def test_additional_hyperparameters(sagemaker_session, chainer_version, chainer_
framework_version=chainer_version,
py_version=chainer_py_version,
)
assert bool(strtobool(chainer.hyperparameters()["sagemaker_use_mpi"]))
assert chainer.hyperparameters()["sagemaker_use_mpi"] in ('y', 'yes', 't', 'true', 'on', '1')
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what strtobool was doing so left it the exact same.

Copy link

codecov bot commented Mar 27, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

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

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     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@akrishna1995 akrishna1995 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/bot run pr

@sagemaker-bot
Copy link
Collaborator

AWS CodeBuild CI Report

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

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

@jmahlik
Copy link
Contributor Author

jmahlik commented Apr 8, 2024

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

@knikure knikure changed the title Distutils removal fix: Distutils removal Apr 16, 2024
@jmahlik
Copy link
Contributor Author

jmahlik commented Apr 16, 2024

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

@knikure
Copy link
Contributor

knikure commented Apr 17, 2024

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

@jmahlik
Copy link
Contributor Author

jmahlik commented Apr 17, 2024

@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:

pytorch_estimator = PyTorch(
entry_point=entry_point,
role=role,
framework_version="1.5.0",
py_version="py3",
instance_count=instance_count,
instance_type=instance_type,
sagemaker_session=pipeline_session,
)

@benieric
Copy link
Contributor

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
Copy link
Contributor Author

jmahlik commented Jun 24, 2024

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.

pytorch_estimator = PyTorch(
entry_point=entry_point,
role=role,
framework_version="1.5.0",
py_version="py3",
instance_count=instance_count,
instance_type=instance_type,
sagemaker_session=pipeline_session,
)

@benieric
Copy link
Contributor

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.

pytorch_estimator = PyTorch(
entry_point=entry_point,
role=role,
framework_version="1.5.0",
py_version="py3",
instance_count=instance_count,
instance_type=instance_type,
sagemaker_session=pipeline_session,
)

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

@jmahlik
Copy link
Contributor Author

jmahlik commented Jun 24, 2024

It doesn't seem that 3.7 is supported by the sdk at all.

python_requires=">= 3.8",
. It won't pip install on 3.7 without hack arounds. 3.7 got removed in 498d94d. 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 benieric reopened this Jul 29, 2024
@benieric
Copy link
Contributor

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.

pytorch_estimator = PyTorch(
entry_point=entry_point,
role=role,
framework_version="1.5.0",
py_version="py3",
instance_count=instance_count,
instance_type=instance_type,
sagemaker_session=pipeline_session,
)

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 (

)

@jmahlik
Copy link
Contributor Author

jmahlik commented Jul 31, 2024

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
Copy link
Contributor

benieric commented Aug 5, 2024

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
Copy link
Collaborator

Hello, do you require any support on this PR?

@jmahlik
Copy link
Contributor Author

jmahlik commented Aug 7, 2024

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
Copy link
Collaborator

sage-maker commented Aug 8, 2024

@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
Copy link
Contributor Author

jmahlik commented Aug 8, 2024

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

@benieric benieric mentioned this pull request Aug 15, 2024
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Runtime dependency on setuptools from importing distutils
6 participants