-
Notifications
You must be signed in to change notification settings - Fork 293
No packages installed when using requirements.txt from pip-tools #261
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
Comments
Thanks for this bug report. I'll take a look at it this evening.. Re your |
dschep
added a commit
that referenced
this issue
Oct 10, 2018
dschep
added a commit
that referenced
this issue
Oct 10, 2018
dschep
added a commit
that referenced
this issue
Oct 10, 2018
dschep
added a commit
that referenced
this issue
Oct 10, 2018
dschep
added a commit
that referenced
this issue
Oct 10, 2018
dschep
added a commit
that referenced
this issue
Nov 1, 2018
dschep
added a commit
that referenced
this issue
Nov 1, 2018
dschep
added a commit
that referenced
this issue
Nov 1, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Our project uses pip-tools to handle dependency pinning. This produces a
requirements.txt
that looks something like this:and so on.
However, when
serverless-python-requirements
processes this file, it produces arequirements.txt
that looks like this:which ultimately results in no packages being installed in
./serverless/requirements/
and thus nothing being injected into the deployment .zip.I've worked around this by having a wrapper script around
pip-compile
which strips out the escaped newlines and joins the separated lines, producing arequirements.txt
more akin to what Pipenv generates. I'd prefer not to have to resort to this hack, though.Additionally, the plugin's default behavior of stripping
boto3
and its dependencies led to surprising behavior:I've added a bogus
noDeploy: ['nonexistent']
configuration to avoid this (even though there's nothing I actually need to exclude), but I'd prefer it if the plugin was either smarter about removing dependencies under the covers, or else a bit dumber about it (i.e. just deploy what's in myrequirements.txt
by default; don't strip things even though they might be redundant).Though this latter problem might seem like it merits a separate issue, I've included it here as it seems like a similar example of the plugin doing a bit too much in the way of mangling the
requirements.txt
that I provide.The text was updated successfully, but these errors were encountered: