Open bxm156 opened 7 years ago
This is a good point. Although, it could potentially break the Doppins (dependency manager).
Some things are pegged because the non-pegged versions break (Kappa), other things are pegged to the most recent for Doppins. Rather than digging into the Zappa requirements right now, I'd rather focus this attention into a previously abandoned effort to add a requirements
setting to use requirements.txts rather than the active venv.
@Miserlou Thats fair, but there is another consideration I wanted to bring up as well.
In the case of the requirements.txt fix you mentioned: If zappa was installed in the local project env, it could create a different version of dependencies that will be used when a user runs tests locally, and when zappa uses the requirements.txt to create a virtualenv for deploy, the resulting env might have slightly different decencies.
Yeah, but IMO that's what CI is for, that's out of scope for Zappa itself.
Has there been any discussion/thoughts about separating the lambda handler requirements and the ci requirements? So that the deploy'd virtualenv only has the min requirements necessary to run the lambda handler, and the lambda handler code itself?
Yeah, there is, I'd be happy to pull that in: https://github.com/Miserlou/Zappa/issues/556
The outdated botocore
is hurting and makes zappa
incompatible with anything requiring a current boto3
.
Context
Since zappa needs to be installed in the same virtualenv as the project, but its requirements seem too restrictive, and might clash with other package requirements in my project's virtualenv. The majority of zappa's requirements are ' == ', when they probably could just be ' >= ', or be more relaxed as far as minor package versions.
For example, why is botocore==1.5.26 ? Would botocore >= 1.5.0 (or some other >= 1.5.x) work just as well?