Deprecate future package and drop Python2 support

[namannandan]

Description

Remove dependence on the future package and references to Python2 in order to resolve security vulnerabilities.

Unregister resnet-18 model after testing load from snapshot in sanity test to avoid subsequent sanity runs from failing.

Fixes #(2063)

Type of change

• Bug fix (non-breaking change which fixes an issue)

Feature/Issue validation/testing

• Sanity test
  CPU: cpu_sanity_log.txt
  GPU: gpu_sanity_log.txt
• Regression test
  CPU: cpu_regression_log.txt
  GPU: gpu_regression_log.txt
• Benchmark
  CPU: cpu_benchmark_log.txt
  GPU: gpu_benchmark_log.txt
• Conda binary testing
  Build and install torchserve conda binaries resulting in the following conda environment:

(ts-conda-test) $ which torchserve
/home/ubuntu/anaconda3/envs/ts-conda-test/bin/torchserve
(ts-conda-test) $ which torch-model-archiver
/home/ubuntu/anaconda3/envs/ts-conda-test/bin/torch-model-archiver
(ts-conda-test) $ which torch-workflow-archiver
/home/ubuntu/anaconda3/envs/ts-conda-test/bin/torch-workflow-archiver
(ts-conda-test) $ pip freeze | grep future
(ts-conda-test) $ python torchserve_sanity.py &> conda_bin_sanity_log.txt

CPU: cpu_conda_bin_sanity_log.txt
GPU: gpu_conda_bin_sanity_log.txt

The conda packages were verified by running the test_torchserve, test_modelarchiver, test_workflow_archiver, test_sanity and test_workflow_sanity methods in the torchserve_sanity script

Checklist:

• Did you have fun?
• Have you added tests that prove your fix is effective or that this feature works?
• Has code been commented, particularly in hard-to-understand areas?
• Have you made corresponding changes to the documentation?

[codecov]

Codecov Report

Merging #2082 (b80f783) into master (8ace3c0) will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2082      +/-   ##
==========================================
- Coverage   53.38%   53.36%   -0.02%     
==========================================
  Files          71       71              
  Lines        3224     3225       +1     
  Branches       56       56              
==========================================
  Hits         1721     1721              
- Misses       1503     1504       +1     

Impacted Files	Coverage Δ
setup.py	0.00% <ø> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[lxning]

@namannandan please also add test log for gpu.

[agunapal]

@namannandan Could you please clarify if python here and in subsequent files in java means python3?

[mreso]

Given that we drop support for Python 2, would it make sense to consolidate the python runtimes into one and rely on the configuration to figure out the right executable?

serve/frontend/server/src/main/java/org/pytorch/serve/util/messages/EnvironmentUtils.java

Line 63 in 2d1bd26

pythonRuntime = configManager.getPythonExecutable();

[namannandan]

@agunapal here, python refers to the system default python binary and would not guarantee that it is aliased to a python3 binary. That would depend on how the environment in which Torchserve is running has been set up. In spite of this, I think there may be use-cases where this could be helpful. Please see my comment below and let me know your thoughts.

@mreso yes, that makes sense to me.
Although, I was wondering if a use-case with the following environment would benefit from having support for both python and python3 runtime options:

• python -> points to the system default python version (say python 3.8)
• python3 -> points to a more recent release of python3 (say python 3.11)

This could give choice between the different python 3.x releases without having to change what python points to. Let me know your thoughts on if this is useful. If not, I can go ahead and remove the reference to python3 as well.

[mreso]

@namannandan yeah, I see your point, though it would look like a hacked together solution and not like a feature to me. Making runtimes configurable and extendable would probably be my preference but there is probably little gain for users out of the non-negligible effort.

[mreso]

Besides the remaining question if we should consolidate runtimes LGTM

[mreso]

Given that we drop support for Python 2, would it make sense to consolidate the python runtimes into one and rely on the configuration to figure out the right executable?

serve/frontend/server/src/main/java/org/pytorch/serve/util/messages/EnvironmentUtils.java

Line 63 in 2d1bd26

pythonRuntime = configManager.getPythonExecutable();

[mreso]

For a period of time we could just map python3 to python with a deprecation warning and instruction to select executable through config.

[namannandan]

@namannandan please also add test log for gpu.

Updated summary to include test logs for GPU.

[namannandan]

Will go ahead and merge this PR since it addresses the major concern about removing the future package. Further improvements to consolidating the runtime options could be made in a future PR.