Ability to have separate local / live builds

[flux627]

Summary

I'm developing a service that uses Pillow, and the dynamic libraries installed only worked when invoked on either my development laptop (OSX) or on AWS, never both, depending on if I compiled using the docker container or not. Having the ability to locally invoke while I'm developing is crucial for speed, so I decided to implement this.

Changes

• sls requirements install local will install dependencies to .local_requirements using the host machine, even if dockerizePip is enabled.
• requirements.py now adds either or both of .requirements and .local_requirements depending on if they exist or not. If .local_requirements exists it will take precedence. Right now I have .local_requirements in my package: exclude:, but I'm not sure if there's any way to force exclude it somehow within the plugin logic.

Other stuff

These are only semi-related to this feature, but I threw them in here anyway as I see them as needed improvements- I can remove if necessary.

• Added --isolated flag to pip to ensure that no global pip settings interfere with installation
• Added -U and --upgrade-strategy=only-if-needed as there is no API for updating packages

I can update the docs, but I wanted feedback on this before I take the time to do that.

Thanks!

[dschep]

Thanks for the pr! I have some ideas relating to #1 that would make this plugin for deployment only, with the intention that you'd just use a virtualenv for local development like you usually would on a python project.

I'll definitely add the --isolated flag and look into the upgrade stuff.

[flux627]

That makes a lot of sense. What ideas do you have for the mechanism for #1?

[dschep]

Mainly: still install to .requirements but when deploying link(soft or hard, soft if they work) to the service's root then unlink them when deploy is done.

[flux627]

I can confirm that soft links are followed when packaged. Sounds good 👍

[dschep]

I've cherry picked the -isolated patch and implemented the linking based solution to #1. I suggest you simply use a virtualenv for local development. The current master is now on npm as a 2.0.0-beta