Added packaging support for whl files. #388

stealthycoin · 2017-06-26T18:07:21Z

The algorithm for building a lambda compatible bundle is as follows:

Download all packages using pip download without specifying binary
preference. This allows it to download whl files where possible and
sdists otherwise.
Try to download lamba-compatible whl files for all sdists
and lambda-incompatible whl files that were downloaded in the first
step. Once this step is completed we have all the whl files are are
going to be able to get from PyPi that are compatible with lambda.
Any sdists left over without a corresponding compatible whl file will
now be built to a whl. If this results in an incompatible whl file there
is nothing more we can do to get a compatible one and it is up to the
user to vendor that package themselves.

Now that we have done our best to get a whl file for each dependency, we
do a final pass over the directory and install all compatible whl files
to the lambda package. Any left over dependencies that do not have a
compatible whl file are reported to the user, as they will need to be
manually added to the vendor directory before deployment.

Virtualenv is no longer used so the compat functionality for it is no
longer needed.

Since the packaging process now downloads whl files which vary by python
version the deployment process now rebuilds the deployment package if it
detects that the python version has changed.

Old PR which stopped sycing with my fork branch for some reason: #382

closes: #249 #227 #364

cc @jamesls @kyleknap @dstufft

codecov-io · 2017-06-26T18:59:17Z

Codecov Report

Merging #388 into master will increase coverage by 0.79%.
The diff coverage is 99.68%.

@@            Coverage Diff             @@
##           master     #388      +/-   ##
==========================================
+ Coverage   92.75%   93.55%   +0.79%     
==========================================
  Files          18       18              
  Lines        2569     2807     +238     
  Branches      334      369      +35     
==========================================
+ Hits         2383     2626     +243     
+ Misses        137      133       -4     
+ Partials       49       48       -1

Impacted Files	Coverage Δ
chalice/package.py	`97.59% <ø> (ø)`	⬆️
chalice/deploy/deployer.py	`90.37% <100%> (ø)`	⬆️
chalice/constants.py	`100% <100%> (ø)`	⬆️
chalice/compat.py	`100% <100%> (+28%)`	⬆️
chalice/utils.py	`95.23% <100%> (+3.71%)`	⬆️
chalice/deploy/packager.py	`95.98% <99.62%> (+5.15%)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2fa94a1...4822615. Read the comment docs.

stealthycoin · 2017-06-26T19:40:19Z

chalice/deploy/packager.py

+class DependencyBuilder(object):
+    """Build site-packages by manually downloading and unpacking whls.
+
+    Pip is used to download all the dependency sdists. Then wheels that


that compatible -> that are compatible

kyleknap

Looks good. Just had some comments/questions. I really only looked through the changes posted in the last two commits from your closed PR since I had looked at the other ones before.

kyleknap · 2017-06-26T19:41:31Z

chalice/deploy/deployer.py

+        # type: (Config, str, str) -> bool
+        if not self._osutils.file_exists(deployment_package_filename):
+            return False
+        lambda_config = self._aws_client.get_function_configuration(


I wonder if we can avoid making this extra GetFunctionConfiguration call? It looks like early there is similar logic: https://github.com/awslabs/chalice/blob/master/chalice/deploy/deployer.py#L499 that we could possibly reuse to save us the extra API call?

It looked like it would require too much refactoring of things not related to my PR so I didn't but yes that call is made twice which is inefficient.

I'd prefer not to make the deployment slower if there's a reasonable workaround here. If you can't do Kyle's suggestion, can we not just add the python version to the deployment package filename? That should avoid a get_function_configuration call with the small cost of being unable to detect out of band (from chalice deploy) changes, which I'm sure will already break the deploy process.

kyleknap · 2017-06-26T19:45:32Z

chalice/deploy/packager.py

+    def _install_purelib_and_platlib(self, whl, root):
+        # type: (Package, str) -> None
+        # Take a wheel package and the directory it was just unpacked into and
+        # properly unpackage the purelib and platlib subdirectories if they


Might be good to explain what "properly" unpackage entails either by expanding the comment or by breaking this function into small internal methods to help explain what each step is?

I'll reword the comment.

Will also be nice to explain the what and why.

kyleknap · 2017-06-26T19:48:21Z

chalice/deploy/packager.py

+        return name, version
+
+
+class PipWrapper(object):


What was the reasoning to have this abstract class when it is subclassed only once?

I subclassed it for testing purposes as well and wanted to ensure that the type signature contract is not broken by the testing class. This way mypy will catch it if either of them get out of sync. I could also move the logic from the SubprocessPip up to PipWrapperand just have the testing inherit from PipWrapper and override the main method. I thought it was clearer what the purpose of everything was this way.

Looks like the typing doesn't actually help the way I thought it did, so I'm not sure exactly how to accomplish what I was trying for here.

kyleknap · 2017-06-26T19:53:25Z

chalice/deploy/packager.py

+        """Execute a pip command with the given arguments."""
+        main_args = [command] + args
+        _, err = self._wrapped_pip.main(main_args)
+        if err:


This seems like it could be potentially flaky in terms of check the standard error for if there is an error. Is there any reason why we just don't use check_call and provide subprocess.PIPE for standard out/error or we just check the rc of the subprocess? That seems it would be a bit more reliable.

Yes it will fail if it fails to get packages, which is not uncommon for smaller simple pure python packages. That is too be expected and not an error. All I really care about is if pip throws us a stack trace of some kind via stderr, and the rc does not vary for that so I can't sense what kind of error it was without parsing stderr.

I talked to @dstufft about this and if I remember correctly this was what we arrived at as the best solution for catching these types of issues.

Offline discussion: Need to talk with donald about this more in detail. But the initial download case can probably rely on rc, there rest will need to tolerate an rc != 1 so we are stuck parsing the stderr.

kyleknap · 2017-06-26T19:58:11Z

chalice/utils.py

+        # type: (str) -> Iterator[Tuple[str, List[str], List[str]]]
+        return os.walk(path)
+
+    def copytree(self, source, destination):


Why can't we just do:

shutil.copytee(source, destination)

It seems that it will handle individual files and directories for you.

https://github.com/python/cpython/blob/master/Lib/shutil.py#L315 which fails if the directory already exists, which in our case it always will. copy/copy2 clobber files and take the directory itself so they are no good either.

Yeah copytree is pretty annoying like that.

kyleknap · 2017-06-26T20:04:09Z

tests/functional/test_package.py

+            packages=[
+                'foo-1.2-cp36-cp36m-manylinux1_x86_64.whl'
+            ],
+            whl_contents=['{data_dir}/purelib/foo/placeholder']


The {data_dir} part is a little confusing for me. What does that represent?

The data directory in an unpacked wheel file.

Offline discussion: Those were there for the implicit case where I do not supply wheel contents and I need to calculate the data directory name anyway so I reused that mechanism. Its clearer to write it out in the explicit tests so I will change it to do that rather than rely on the format string.

kyleknap · 2017-06-26T20:05:44Z

tests/functional/test_package.py

+            packages=[
+                'foo-1.2-cp36-cp36m-manylinux1_x86_64.whl'
+            ],
+            whl_contents=['{data_dir}/platlib/foo/placeholder']


Also I am not very sure what the placeholder part of the string for whl_contents represents. Could you elaborate on what the placeholder is for?

I just need a garbage file in the directory so that folder exists. Maybe I'm conflating how zip works with how git works. I didn't try it without the placeholders.

Offline discussion: removed the placeholder, I didn't realize empty folders worked in zip/tar for some reason.

jamesls

I've been trying this out locally and it's worked really well so far. I had some comments about the APIs and how the code is structured. Haven't had a chance to go through all the tests yet but wanted to get some early feedback first.

jamesls · 2017-06-26T23:31:23Z

chalice/deploy/deployer.py

+        # type: (Config, str, str) -> bool
+        if not self._osutils.file_exists(deployment_package_filename):
+            return False
+        lambda_config = self._aws_client.get_function_configuration(


I'd prefer not to make the deployment slower if there's a reasonable workaround here. If you can't do Kyle's suggestion, can we not just add the python version to the deployment package filename? That should avoid a get_function_configuration call with the small cost of being unable to detect out of band (from chalice deploy) changes, which I'm sure will already break the deploy process.

jamesls · 2017-06-26T23:35:23Z

chalice/utils.py

+            os.makedirs(destination)
+        names = os.listdir(source)
+        for name in names:
+            new_source = os.path.join(source, name)


I think we should try to use the osutils methods where possible. This makes it easier to write alternate implementations without having to implement all the methods. So self.joinpath here instead of os.path.join.

jamesls · 2017-06-26T23:35:58Z

chalice/utils.py

+
+    @contextlib.contextmanager
+    def tempdir(self):
+        # type: () -> Any


Seems like we can restrict the type further than Any.

jamesls · 2017-06-26T23:36:25Z

setup.py

    'typing==3.5.3.0',
    'six>=1.10.0,<2.0.0',
+    'pip>=9'


We should at least bind to a major version, so 9.x only.

This is a bit tricky to do with pip I think, because while we're not setuptools style, we do rev our versions fairly regularly, but our breaking changes tend to be removing things that few people use rather than completely changing the common paths. So while we could do this, we should expect to need to rev this once or twice a year.

Once or twice a year seems reasonable, I'm just concerned that it's still a possibility within semver to break a common API (even if it's rare), and people on older versions of chalice won't be guarded against this.

jamesls · 2017-06-26T23:43:37Z

chalice/deploy/packager.py

-        virtualenv.create_environment(venv_dir)
+    def __init__(self, dependency_builder=None):
+        # type: (Optional[DependencyBuilder]) -> None
+        self._osutils = OSUtils()


The common pattern we use is that either the object that requires the dependency is responsible for defaulting it, or the very top level code (factories/entry points etc) constructs the dependency. So I'd suggest moving the OSUtils() construction all the way up to the factory function, or down to DependencyBuilder (not my preference).

jamesls · 2017-06-27T17:32:25Z

chalice/deploy/packager.py

+        # Sort the downloaded packages into three categories:
+        # - sdists (Pip could not get a wheel so it gave us a sdist)
+        # - valid whls (lambda compatbile wheel files)
+        # - invalid whls (lambda incompatible wheel files)


Why not just call it that (lambda_incompatible_wheels) rather than have a comment about what an "invalid whl" is?

Or just compatible / incompatible if you want to keep it shorter. I think there's enough context for that to make sense.

jamesls · 2017-06-27T17:39:00Z

chalice/deploy/packager.py

+        valid_whls, invalid_whls = self._categorize_whl_files(directory)
+        sdists = deps - valid_whls - invalid_whls
+
+        # Find which packages we do not yet have a valid whl file for. And


I think I've made this comment before, but rather than explaining what the code is doing, it would really helpful if you explain why you're doing this. As someone not as familiar with the intricacies of pip, a high level overview of why we're doing this multipass approach, why an invalid wheel might be able to be "converted" to a valid manylinux1 wheel, etc. Putting a more detailed explanation of your algorithm outlined in the PR description would be better in the code itself IMO.

jamesls · 2017-06-27T17:42:07Z

chalice/deploy/packager.py

+        # type: (str, str, Set[Package]) -> None
+        if os.path.isdir(dst_dir):
+            shutil.rmtree(dst_dir)
+        os.makedirs(dst_dir)


If you're introducing OSUtils as a dependency for this object, the point of that is it abstracts all os operations to allow for granular testing, error conditions, etc. Using shutil and os directly in the same object defeats that purpose.

jamesls · 2017-06-27T17:43:33Z

chalice/deploy/packager.py

+class PipWrapper(object):
+    def main(self, args):
+        # type: (List[str]) -> Tuple[Optional[bytes], Optional[bytes]]
+        raise NotImplementedError('PipWrapper.main')


I think we usually just use the method name and not the base class. If a subclass doesn't implement this they'll see the base class's name in the error message which can be confusing.

jamesls · 2017-06-27T17:46:30Z

chalice/deploy/packager.py

+        arguments = ['-r', requirements_file, '--dest', directory]
+        self._execute('download', arguments)
+
+    def download_manylinux_whls(self, packages, directory):


Nitpick, but it's not 100% consistent in this code if we use "wheel" or "whl" (build_wheel vs. download_manylinux_whls. FWIW, I prefer "wheel", it's two extra characters, makes it more readable, and is the name of the concept, whereas "whl" is the file extension.

JordonPhillips

Much better descriptions. Had a pass at the code itself but not the tests yet.

JordonPhillips · 2017-06-29T22:44:59Z

chalice/constants.py

+
+Your deployment will continue but may not work correctly
+if missing dependencies are not present. For more information:
+http://chalice.readthedocs.io/en/latest/topics/packaging.html


You should probably update this to include information about this feature.

Got a draft up.

JordonPhillips · 2017-06-29T22:54:58Z

chalice/deploy/packager.py

+            dependency_builder = DependencyBuilder(self._osutils)
+        self._dependency_builder = dependency_builder
+
+    def _get_requirements_file(self, project_dir):


JordonPhillips · 2017-06-29T23:04:56Z

chalice/deploy/packager.py

+    into a site-packages directory, to be included in the bundle by the
+    packager.
+    """
+    _MANYLINUX_COMPATIBLE_PLAT = {'any', 'linux_x86_64', 'manylinux1_x86_64'}


JordonPhillips · 2017-06-29T23:15:43Z

chalice/deploy/packager.py

+        # which will serve as the master list of dependencies needed to deploy
+        # successfully.
+        self._pip.download_all_dependencies(requirements_file, directory)
+        deps = {Package(directory, filename) for filename


Finally a project where we can use dict comprehensions

JordonPhillips · 2017-06-29T23:28:33Z

chalice/deploy/packager.py

+        # Sort the downloaded packages into three categories:
+        # - sdists (Pip could not get a wheel so it gave us a sdist)
+        # - valid whls (lambda compatbile wheel files)
+        # - invalid whls (lambda incompatible wheel files)


Or just compatible / incompatible if you want to keep it shorter. I think there's enough context for that to make sense.

JordonPhillips · 2017-06-30T22:54:26Z

chalice/deploy/packager.py

+        p = subprocess.Popen(cmd, cwd=package_dir,
+                             stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+        p.communicate()
+        self._osutils.joinpath(egg_info_dir)


This isn't being used, and only has one argument anyway which I'm not sure makes sense.

JordonPhillips · 2017-06-30T22:56:46Z

chalice/deploy/packager.py

+        p.communicate()
+        self._osutils.joinpath(egg_info_dir)
+        info_contents = self._osutils.get_directory_contents(egg_info_dir)
+        assert len(info_contents) == 1


Again, I'm not sure the user experience will be great if this condition fails.

JordonPhillips · 2017-06-30T23:01:27Z

chalice/deploy/packager.py

+
+class PipRunner(object):
+    """Wrapper around pip calls used by chalice."""
+


Sorry to nitpick, but this is the only place you've got a space between the class doc string and the first method.

JordonPhillips · 2017-06-30T23:14:20Z

chalice/utils.py

+        with tarfile.open(tarfile_path, 'r:gz') as tar:
+            tar.extractall(unpack_dir)
+
+    def directory_exists(self, path):


These should probably stay close to the names of the functions they're aliasing.

JordonPhillips · 2017-06-30T23:15:22Z

chalice/utils.py

+        # type: (str) -> Iterator[Tuple[str, List[str], List[str]]]
+        return os.walk(path)
+
+    def copytree(self, source, destination):


Yeah copytree is pretty annoying like that.

jamesls

Just had some minor feedback. I think this latest version is looking good. Only major piece missing is updated packaging docs.

jamesls · 2017-07-03T20:00:30Z

chalice/utils.py

@@ -92,6 +98,15 @@ def get_file_contents(self, filename, binary=True):
        with open(filename, mode) as f:
            return f.read()

+    @contextlib.contextmanager
+    def get_file_context(self, filename, mode='r'):


Why is this needed? Is there a reason you can't use OSUtils.open directly?

jamesls · 2017-07-03T20:02:23Z

chalice/utils.py

@@ -101,6 +116,84 @@ def set_file_contents(self, filename, contents, binary=True):
        with open(filename, mode) as f:
            f.write(contents)

+    def unpack_zipfile(self, zipfile_path, unpack_dir):


This is picky, but I think we should use verbs that are commonly associated with whatever the noun is, so for a zipfile, I would expect "unzip", or "extract" but not "unpack".

jamesls · 2017-07-03T20:05:44Z

chalice/utils.py

+            z.extractall(unpack_dir)
+
+    @contextlib.contextmanager
+    def zipfile_context(self, filename, mode='r',


Why do we need to wrap the zipfile with its own context manager? This is already a capability of zipfile.ZipFile so it seems unnecessary.

jamesls · 2017-07-03T20:06:08Z

chalice/utils.py

+        finally:
+            z.close()
+
+    def unpack_tarfile(self, tarfile_path, unpack_dir):


Same comment as zip. Maybe "untar" or "extract"

jamesls · 2017-07-03T20:07:57Z

setup.py

    'typing==3.5.3.0',
    'six>=1.10.0,<2.0.0',
+    'pip>=9'


Once or twice a year seems reasonable, I'm just concerned that it's still a possibility within semver to break a common API (even if it's rare), and people on older versions of chalice won't be guarded against this.

jamesls · 2017-07-03T20:16:31Z

chalice/deploy/packager.py

+            raise InvalidSourceDistributionNameError(sdist_path)
+        # There should only be one directory unpacked.
+        contents = self._osutils.get_directory_contents(unpack_dir)
+        assert len(contents) == 1


I think I may have either added this or a similar assertion somewhere in the packager code. I would also suggest removing these assertions. The only reason I added them previously was during the initial POC and they just never got removed. They generate unhelpful error messages. If this is a case a customer can run into, raise a specific exception, otherwise remove the assertion.

jamesls · 2017-07-03T20:21:30Z

chalice/deploy/packager.py

+        try:
+            requirements_filepath = self._get_requirements_filename(
+                project_dir)
+            site_packages_dir = self._osutils.joinpath(


Does this directory not need to be python version aware? How does it handle the case where the python version is switched and different requirements are specified? Wouldn't it be safer to just have a separate py-specific site-packages directory to avoid any possibility of invalid packages?

Site packages are not reused, I was considering deleting it, the only reason its not deleted was for debugging purposes so I could see what the folder looked like, its convenient if something goes wrong to be able to see what was packaged before and after vendoring.

Ah, I missed that that happens in _install_wheels. While it seems a little surprising that a method like build_site_packages will wipe out the target_directory if it exists (arguably even dangerous), seems like my original concern isn't an issue.

I suppose there are three options:

Delete it first and rebuild which is safe with regards to building a working site-packages directory. Not safe if contents was pre-merged in rather than post-merged in like we do currently.

Merge content. Not safe since python versions can change or get removed.

Error out.

So either:

Leave the code as is.

I leave the directory there after its built, but delete it in the caller of build_site_packages and have the it error out if the directory exists.

Delete it after the package finishes building, and have build_site_packages error out if the directory already exists.

My preference is option 1 or 2 since I like having directory there "just in case" you need to investigate it for some reason.

I'm ok with option 2. That allows build_site_packages to just focus on populating the directory and it's the caller's responsibility to put it into whatever state it needs to be (empty in this case).

Though my personal preference would be to just delete the directory. It's of no use to chalice users (we don't reuse the directory across deploys) and it just takes up space. If we want dev debugging hooks, we can always add them later and explicitly turn them on (or ask users to run with debugging mode enabled).

I can just nuke the directory and we can allow debugging options later. The debug hooks would need to give you access to it rather than just logging it though since sometimes you need to go look in files and go pretty deep into nested directories, more than a simple log will give.

Ok that seems fine. Though in that case you can just use a OSUtils.tempdir so it can handle cleaning up the directory when you're done.

Yep thats the plan. The debug hook can copy it out somewhere before it gets erased.

jamesls

Docs looks good, just had a few suggestions.

jamesls · 2017-07-03T23:38:57Z

docs/source/topics/packaging.rst

-  run ``pip install -r requirements.txt`` in a virtual environment
-  and automatically install 3rd party python packages into the deployment
-  package.
+  install any packages it find or build compatible wheels for. Specifically


I think the wording is off here. Did you mean "...install any packages it finds or builds compatible wheels for" maybe?

jamesls · 2017-07-03T23:39:12Z

docs/source/topics/packaging.rst

-  and automatically install 3rd party python packages into the deployment
-  package.
+  install any packages it find or build compatible wheels for. Specifically
+  all pure python projects as well as all projects that upload wheel files for


What about packages instead of projects?

kyleknap

It looks good. But one general comment that I have is that it would be nice if the literal commands that need to be ran were present (sort of what the pyscopg2 example had). It is pretty convenient that I can blindly copy and paste the commands I need to run instead of read the entire document and try to interpret the command that I need to run.

kyleknap · 2017-07-05T17:50:08Z

docs/source/topics/packaging.rst

+`cryptography <https://pypi.python.org/pypi/cryptography>`__ package in a
+Chalice app for the ``python3.6`` lambda environment.
+
+We're going to leverage the ``vendor/`` directory in order to use this package


It might be worth making the mention that since chalice will try to build the wheel for you and you are on the right system, it may be able to work via the requirements.txt. I am only suggesting it because it came off to me as cryptography will require additional steps to be part of the deployment package.

What about just saying something like "Suppose we're on a Mac and we want to deploy an app that uses cryptography". That keeps it more user-centric and less about implementation details of chalice building wheels. You could also say that this wouldn't be an issue if we were on the same platform that Lambda uses.

That would be fine as well. I just want to make sure a user sees this and does not immediately start trying to follow the steps when it actually would have worked for them to start.

JordonPhillips

Code looks good, docs look good, just a pair of very minor comments on some of the tests.

JordonPhillips · 2017-07-05T17:41:23Z

tests/functional/test_package.py

+    def _build_fake_sdist(self, filepath):
+        # tar.gz is the same no reason to test it here as it is tested in
+        # unit.deploy.TestSdistMetadataFetcher
+        assert filepath.endswith('zip')


Ah, thought I caught all those.

JordonPhillips · 2017-07-05T17:50:03Z

tests/functional/test_package.py

+        installed_packages = os.listdir(site_packages)
+
+        pip.validate()
+        for req in reqs:


There's only one of these so it's a bit odd to iterate. This happens in a few other places as well.

Makes it easy to update the tests if I need to.

Yeah I'm -0 on keeping them. This is not a PR blocker.

jamesls

Looks good to me, aside from pending feedback from Kyle/Jordon.

kyleknap

Looks good! 🚢

The algorithm for building a lambda compatible bundle is as follows: 1) Download all packages using pip download without specifying binary preference. This allows it to download whl files where possible and sdists otherwise. 2) Try to download lamba-compatible whl files for all sdists and lambda-incompatible whl files that were downloaded in the first step. Once this step is completed we have all the whl files are are going to be able to get from PyPi that are compatible with lambda. 3) Any sdists left over without a corresponding compatible whl file will now be built to a whl. If this results in an incompatible whl file there is nothing more we can do to get a compatible one and it is up to the user to vendor that package themselves. Now that we have done our best to get a whl file for each dependency, we do a final pass over the directory and install all compatible whl files to the lambda package. Any left over dependencies that do not have a compatible whl file are reported to the user, as they will need to be manually added to the vendor directory before deployment. Virtualenv is no longer used so the compat functionality for it is no longer needed. Since the packaging process now downloads whl files which vary by python version the deployment process now rebuilds the deployment package if it detects that the python version has changed.

Interface for creating a site packages directory from a requirements file has changed to no longer make any assumptions about the chalice directory structure. The python version was appended to the end of a package name to prevent needing to query for the last deployed python version twice.

Updated the packaging documentation and addressed some minor feedback items.

And a very minor test change.

stealthycoin force-pushed the whl-packaging branch 2 times, most recently from 73add2c to 12ce5f3 Compare June 26, 2017 18:16

stealthycoin requested review from dstufft, jamesls and kyleknap June 26, 2017 19:18

stealthycoin commented Jun 26, 2017

View reviewed changes

kyleknap reviewed Jun 26, 2017

View reviewed changes

jamesls reviewed Jun 27, 2017

View reviewed changes

JordonPhillips self-requested a review June 29, 2017 22:41

JordonPhillips reviewed Jun 30, 2017

View reviewed changes

stealthycoin force-pushed the whl-packaging branch from aa91366 to ded9ee3 Compare July 3, 2017 17:46

jamesls reviewed Jul 3, 2017

View reviewed changes

stealthycoin force-pushed the whl-packaging branch 2 times, most recently from 9c217f1 to d89826c Compare July 3, 2017 23:25

jamesls reviewed Jul 3, 2017

View reviewed changes

stealthycoin force-pushed the whl-packaging branch from d89826c to 5d8baf6 Compare July 4, 2017 00:14

kyleknap reviewed Jul 5, 2017

View reviewed changes

JordonPhillips reviewed Jul 5, 2017

View reviewed changes

jamesls approved these changes Jul 5, 2017

View reviewed changes

kyleknap approved these changes Jul 5, 2017

View reviewed changes

stealthycoin force-pushed the whl-packaging branch from 863ac8d to 4822615 Compare July 5, 2017 20:34

JordonPhillips approved these changes Jul 5, 2017

View reviewed changes

jcarlyl added 6 commits July 5, 2017 13:38

Documentation update.

96ee860

Updated the packaging documentation and addressed some minor feedback items.

Replaced the .chalice/site-packages directory with a tempdir.

80a0b22

Documentation update, added more details to example scenario.

d381e7a

And a very minor test change.

Updated changelog.

dd7e0a2

stealthycoin force-pushed the whl-packaging branch from 4822615 to dd7e0a2 Compare July 5, 2017 20:39

stealthycoin merged commit b02dd2e into aws:master Jul 5, 2017

stealthycoin deleted the whl-packaging branch July 5, 2017 20:40

This was referenced Jul 31, 2017

Support for egg-links #227

Closed

chalice deploy returned non-zero exit status 1 #69

Closed

kislyuk mentioned this pull request Aug 24, 2017

Manage wheels that Chalice can't find HumanCellAtlas/data-store#379

Merged


		class PipRunner(object):
		"""Wrapper around pip calls used by chalice."""

Added packaging support for whl files. #388

Added packaging support for whl files. #388

Conversation

stealthycoin commented Jun 26, 2017 • edited Loading

codecov-io commented Jun 26, 2017 • edited Loading

Codecov Report

Choose a reason for hiding this comment

kyleknap left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stealthycoin Jun 26, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jamesls left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JordonPhillips left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jamesls left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stealthycoin Jul 4, 2017 • edited Loading

Choose a reason for hiding this comment

jamesls left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stealthycoin commented Jun 26, 2017 •

edited

Loading

codecov-io commented Jun 26, 2017 •

edited

Loading

stealthycoin Jun 26, 2017 •

edited

Loading

stealthycoin Jul 4, 2017 •

edited

Loading