generated from tweag/project
-
Notifications
You must be signed in to change notification settings - Fork 16
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
Refactor real_projects
tests to support Windows
#406
Comments
jherland
added a commit
that referenced
this issue
Jan 20, 2024
This fixes issue #406. Instead of generating lines of a shell script that need to be run with shell=True in subprocess.run(), generate a sequence of argv-style commands. These are safer (no shell involved) and more easily portable to Windows (for one, our quoting of command line args on Windows was dubious, at best...). Also move the first and last commands in the previous shell script (i.e. the preliminary removal of venv_dir, and the creation of the venv_dir/.installed marker file) out of venv_script_lines() and into the __call__() method. Since these are no longer part of the generated commands, they are also no longer part of the venv_hash(). If we make changes to these two steps (without making any other changes that are captured by venv_hash(), we will end up reusing a cache entry. If this is problematic, then some other modification to change the venv_hash() must be added at the same time.
jherland
added a commit
that referenced
this issue
Jan 25, 2024
This fixes issue #406. Instead of generating lines of a shell script that need to be run with shell=True in subprocess.run(), generate a sequence of argv-style commands. These are safer (no shell involved) and more easily portable to Windows (for one, our quoting of command line args on Windows was dubious, at best...). Also move the first and last commands in the previous shell script (i.e. the preliminary removal of venv_dir, and the creation of the venv_dir/.installed marker file) out of venv_script_lines() and into the __call__() method. Since these are no longer part of the generated commands, they are also no longer part of the venv_hash(). If we make changes to these two steps (without making any other changes that are captured by venv_hash(), we will end up reusing a cache entry. If this is problematic, then some other modification to change the venv_hash() must be added at the same time.
jherland
added a commit
that referenced
this issue
Feb 29, 2024
This fixes issue #406. Instead of generating lines of a shell script that need to be run with shell=True in subprocess.run(), generate a sequence of argv-style commands. These are safer (no shell involved) and more easily portable to Windows (for one, our quoting of command line args on Windows was dubious, at best...). Also move the first and last commands in the previous shell script (i.e. the preliminary removal of venv_dir, and the creation of the venv_dir/.installed marker file) out of venv_script_lines() and into the __call__() method. Since these are no longer part of the generated commands, they are also no longer part of the venv_hash(). If we make changes to these two steps (without making any other changes that are captured by venv_hash(), we will end up reusing a cache entry. If this is problematic, then some other modification to change the venv_hash() must be added at the same time.
jherland
added a commit
that referenced
this issue
Mar 7, 2024
This fixes issue #406. Instead of generating lines of a shell script that need to be run with shell=True in subprocess.run(), generate a sequence of argv-style commands. These are safer (no shell involved) and more easily portable to Windows (for one, our quoting of command line args on Windows was dubious, at best...). Also move the first and last commands in the previous shell script (i.e. the preliminary removal of venv_dir, and the creation of the venv_dir/.installed marker file) out of venv_script_lines() and into the __call__() method. Since these are no longer part of the generated commands, they are also no longer part of the venv_hash(). If we make changes to these two steps (without making any other changes that are captured by venv_hash(), we will end up reusing a cache entry. If this is problematic, then some other modification to change the venv_hash() must be added at the same time.
jherland
added a commit
that referenced
this issue
Mar 11, 2024
This fixes issue #406. Instead of generating lines of a shell script that need to be run with shell=True in subprocess.run(), generate a sequence of argv-style commands. These are safer (no shell involved) and more easily portable to Windows (for one, our quoting of command line args on Windows was dubious, at best...). Also move the first and last commands in the previous shell script (i.e. the preliminary removal of venv_dir, and the creation of the venv_dir/.installed marker file) out of venv_script_lines() and into the __call__() method. Since these are no longer part of the generated commands, they are also no longer part of the venv_hash(). If we make changes to these two steps (without making any other changes that are captured by venv_hash(), we will end up reusing a cache entry. If this is problematic, then some other modification to change the venv_hash() must be added at the same time.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From a discussion on #397:
Since we're adding a section for Windows here that returns on its own, I guess we can leave the POSIX arm below unchanged? In other words, make the whole function this?:
But as soon as I suggest that, I'm starting to see some more cracks forming here:
Taking a step back and examining what this function is actually used for: This is not just returning an awkward shell script to be passed to
subprocess.run(" && ".join(venv_script), ...)
below. It is also used to create the string we return fromvenv_hash()
, and this string should remain stable as long as the Python version, thevenv_path
(artificially fixed) and the script itself does not change. However, we're now introducingsys.executable
into this script, and I don't know if this is always stable between successive CI runs (a CI runner could have the same Python installed in a different location).Still, I'm not sure it's worth doing too much about this: The failure mode would be for the hash to update needlessly which would cause Windows tests to not benefit from the caching we're implementing here. Probably not too bad, all things considered.
To be clear: Since we're disabling
real_projects
on Windows for now, anyway, I'm happy for you to push all of these related suggestions to a later issue/PR. 😄...because there are also some other minor things that I would like to change:
{venv_path}/bin/python -m pip install ...
instead of{venv_path}/bin/pip install ...
in the POSIX version as well.yield
instead...Here's an attempt to rewrite this function into something that is hopefully more robust, while keeping the overall design (which arguably should be rewritten altogether, at some point):
Originally posted by @jherland in #397 (comment)
The text was updated successfully, but these errors were encountered: