-
Notifications
You must be signed in to change notification settings - Fork 1k
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 environment variables being passed to subprocess while packaging #504
Fix environment variables being passed to subprocess while packaging #504
Conversation
Codecov Report
@@ Coverage Diff @@
## master #504 +/- ##
==========================================
+ Coverage 94.01% 94.12% +0.11%
==========================================
Files 18 18
Lines 2941 2946 +5
Branches 380 381 +1
==========================================
+ Hits 2765 2773 +8
+ Misses 129 126 -3
Partials 47 47
Continue to review full report at Codecov.
|
2b415a9
to
e005df9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I just had some small suggestions.
chalice/utils.py
Outdated
@@ -78,6 +78,10 @@ def create_zip_file(source_dir, outfile): | |||
class OSUtils(object): | |||
ZIP_DEFLATED = zipfile.ZIP_DEFLATED | |||
|
|||
def environ(self): | |||
# type: () -> Dict[str,str] | |||
return os.environ.copy() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we be caching the copy of the os.environ on the first call and then return the cached copy on subsequent calls? Mainly just wondering in the case that if we update the environement variables that gets returned, the update will not actually get returned again if OSUtils.environ
gets called again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not needed for this particular use case but that is a reasonable expectation of someone consuming the OSUtils
class in general so I will add it.
@@ -162,9 +163,17 @@ def osutils(): | |||
|
|||
|
|||
@pytest.fixture | |||
def pip_runner(): | |||
def empty_env_osutils(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it makes sense to subclass from OSUtils
for the EmptyEnv
class?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It won't really help or hurt anything in terms of the actual code, but it may make it clearer to someone reading the tests where this came from and what (partial) interface its trying to replace so I will update that.
tests/unit/deploy/test_packager.py
Outdated
@@ -46,6 +46,26 @@ def pip_runner(): | |||
|
|||
|
|||
@pytest.fixture | |||
def custom_env_osutils(): | |||
class CustomEnv(object): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thing here about subclassing from OSUtils
.
|
||
@pytest.fixture | ||
def pip_runner_custom_env(custom_env_osutils): | ||
def create_pip_runner(env): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So idea. What if instead of making a bunch of different pip runners, we just made a pip_runner_factory
fixture? That way if we add anything more to the PipRunner()
class, we do not have to add a new fixture for each of these.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I mainly didn't want to change the interface used in every single test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Capturing offline feedback:
- Remove usage of
.copy()
for env vars - Clean up compat.py if
subprocess_python_base_environ
isn't needed anymore.
e005df9
to
5784fae
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Just a couple of comments about removing some potential dead test fixtures.
|
||
|
||
@pytest.fixture | ||
def pip_runner_custom_env(custom_env_osutils): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be removed now that it is no longer used.
@@ -78,6 +79,10 @@ def create_zip_file(source_dir, outfile): | |||
class OSUtils(object): | |||
ZIP_DEFLATED = zipfile.ZIP_DEFLATED | |||
|
|||
def environ(self): | |||
# type: () -> MutableMapping | |||
return os.environ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that works too as long as we were not just returning back a copy each time.
|
||
|
||
@pytest.fixture | ||
def pip_runner(empty_env_osutils): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need the pip_runner
fixture anymore after the refactor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the alternative? The pip_runner
fixture is used in numerous tests still. I'm not following.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was referring to the fact that he switched out the use of pip_runner
with pip_factory
. I was not sure if the pip_runner
fixture was being used anymore. When I did a quick check, I did not see it being used anywhere else in the test_package.py
file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost all the tests in TestDependencyBuilder
in the class below use this. Am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nevermind. I was looking at the tests/unit/deploy/test_packager.py
file when I was going over the file. The tests/functional/test_package.py
definitely needs it. Did not help that the same fixture was duplicated in two different test files instead of having it in the conftest.py
.
#504 * stealthycoin-fix-path-passed-during-packaging: Remove unused fixture Add entry to CHANGELOG Fix environment variables being passed to subprocess while packaging
Fixes #501
cc @kyleknap @jamesls @JordonPhillips @dstufft