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

[runtime env] Support clone virtualenv from an existing virtualenv #22309

Merged
merged 7 commits into from
Feb 15, 2022

Conversation

Catch-Bull
Copy link
Contributor

Why are these changes needed?

Before this PR, we can't run ray in virtualenv, cause runtime_env does not support create a new virtualenv from an existing virtualenv.

More details:#21801 (comment)

Related issue number

Checks

  • I've run scripts/format.sh to lint the changes in this PR.
  • I've included any doc changes needed for https://docs.ray.io/en/master/.
  • I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
  • Testing Strategy
    • Unit tests
    • Release tests
    • This PR is not tested :(

virtualenv_path,
]
logger.info(
"Creating virtualenv at %s," " current python dir %s",
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you remove the " " in the string?

Copy link
Contributor

Choose a reason for hiding this comment

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

Please use f-string

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Please use f-string

the reason why we use % instead of f-string in logger is in here: #21801 (comment)

virtualenv_path,
]
logger.info(
"Colning virtualenv %s to %s", current_python_dir, virtualenv_path
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
"Colning virtualenv %s to %s", current_python_dir, virtualenv_path
"Cloning virtualenv %s to %s", current_python_dir, virtualenv_path

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thx! Fixed.

@@ -84,6 +84,7 @@ pytest-rerunfailures
pytest-sugar
pytest-lazy-fixture
pytest-timeout
pytest-virtualenv
scikit-learn==0.22.2
tensorflow==2.5.1
testfixtures
Copy link
Contributor

@fyrestone fyrestone Feb 11, 2022

Choose a reason for hiding this comment

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

Can we add the virtualenv-clone to requirements.txt? @edoakes

Copy link
Contributor Author

@Catch-Bull Catch-Bull Feb 11, 2022

Choose a reason for hiding this comment

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

@edoakes virtualenv-clone is just a script in only one file, I can copy it to $RAY_HOME/python/ray/_private/runtime_env/clonevirtualenv.py

https://github.com/edwardgeorge/virtualenv-clone/blob/master/clonevirtualenv.py

Copy link
Contributor Author

@Catch-Bull Catch-Bull Feb 11, 2022

Choose a reason for hiding this comment

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

Can we add the virtualenv-clone to requirements.txt? @edoakes

I believe you mean is add the virtualenv-clone to ray's requirements in setup.py

Copy link
Contributor

Choose a reason for hiding this comment

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

better if we can copy it instead of adding another dependency

Copy link
Contributor

Choose a reason for hiding this comment

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

cc @pcmoritz virtualenv-clone has an MIT license -- are we ok to pull it into the repo?

if cls._is_in_virtualenv():
# TODO(fyrestone): Handle create virtualenv from virtualenv.
# virtualenv-clone homepage:
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you please add a comment about why we need virtualenv-clone in this case? It's clear from the PR description and the previous PR, but it would be good to have it as a comment in the code for easier reference.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Could you please add a comment about why we need virtualenv-clone in this case? It's clear from the PR description and the previous PR, but it would be good to have it as a comment in the code for easier reference.

virtualenv-clone README have some reasons why we shouldn't use virtualenv to relocate virtualenv:

Virtualenv provides a way to make virtualenv's relocatable which could then be copied as we wanted. 
However making a virtualenv relocatable this way breaks the no-site-packages isolation of the virtualenv 
as well as other aspects that come with relative paths and /usr/bin/env shebangs that may be undesirable.

Also, the .pth and .egg-link rewriting doesn't seem to work as intended. This attempts to overcome these 
issues and provide a way to easily clone an existing virtualenv.

Example: If we don't rewrite .pth file in new_venv, and this file directory to old_venv sit-package's dir, then the package A which in old_venv sit-package's dir got changed, the package A of new_venv will also change accordingly.


# Run current test case in virtualenv again.
# If the command exit code is not zero, this case will be failed.
cloned_virtualenv.run(f"IN_VIRTUALENV=1 python -m pytest {__file__}")
Copy link
Contributor

Choose a reason for hiding this comment

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

How does this make test_run_in_virtualenv fail? Do we need to assert that the exit code is nonzero somewhere?

Also, if it fails, will the test output be printed somewhere? If not, it could be hard to debug.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How does this make test_run_in_virtualenv fail? Do we need to assert that the exit code is nonzero somewhere?

Also, if it fails, will the test output be printed somewhere? If not, it could be hard to debug.

We don't need to assert exit_code != 0, this pytest-plugin will raise an exception when return_code != 0, and this Exception will construct by this pytest-cmd's stderr, so we may not worry about debug.

Copy link
Contributor

@architkulkarni architkulkarni left a comment

Choose a reason for hiding this comment

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

Thanks for this follow-up! Looks good to me, once we resolve what to do about including virtual-clone as a dependency or vendoring it

OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
"""

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@edoakes Can you accept I include clone-virtualenv like this?

@architkulkarni @edoakes And do you have any other comments for this PR?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes this looks good

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it's okay to include it like this. According to this https://dwheeler.com/essays/floss-license-slide.html the MIT license is permissive and can be included in a project that uses the Apache license (which is what Ray uses).

Copy link
Contributor

Choose a reason for hiding this comment

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

No other comments from me!

@edoakes edoakes merged commit 4c73560 into ray-project:master Feb 15, 2022
@rkooo567 rkooo567 removed their assignment Feb 16, 2022
simonsays1980 pushed a commit to simonsays1980/ray that referenced this pull request Feb 27, 2022
ray-project#22309)

Before this PR, we can't run ray in virtualenv, cause `runtime_env` does not support create a new virtualenv  from an existing virtualenv.

More details:ray-project#21801 (comment)

Co-authored-by: 捕牛 <[email protected]>
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.

6 participants