Skip to content

requirements.txt file dependencies are shuffled from the original file #592

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

Open
ahmed-sharief5 opened this issue Mar 5, 2021 · 2 comments
Labels

Comments

@ahmed-sharief5
Copy link

Shuffling of dependencies in requirements.txt inside .serverless directory causing a dependency error while installing other dependency during sls deploy. Could you please resolve this or is there any solution for this

@bsamuel-ui
Copy link
Contributor

The typical solution is "use poetry or pipenv" as they do a lot of work to manage dependencies for you.

The sorting was done in #165 to help static caching of requirements work.

@AndrewFarley given that requirements can be order sensitive, should we simply not sort them? This doesn't seem like it would commonly defeat caching. Alternatively, could we could sort only a copy of the requirements when doing the cache lookup?

@bsamuel-ui bsamuel-ui added the bug label Apr 11, 2021
@f00f
Copy link

f00f commented Aug 3, 2022

I think sorting and comment-removal do make sense, for more matches between projects. However, doing that on a copy with the sole purpose to derive the hash, and not touching the actual file makes sense, too.

The filtering and sorting is done in function generateRequirementsFile in the file lib/pip.js. This also removes noDeploy requirements, which is intended. So the suggestion would be to filter out noDeploy (and maybe comments), then write that filtered file, as this is what packaging should be using. Apply comment-filtering and sorting to the contents of that file and derive the hash from that normalized content.

On a side note: would it make sense to also take the value of provider.runtime into account for the hash? Changing the runtime has led to broken deploys for us.
(note: that change would probably have to be in function md5Path(fullpath) in the file lib/shared.js, or in the place(s) where that function is used)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants