Closed demeringo closed 3 weeks ago
The requirements.txt is used in clever-cloud for the public endpoint. Could we make a GitHub action that updates automatically the requirements.txt every time poetry dependency are updated ?
Why is there a Pipfile it the repo ? Why do we need it ? Is the "pyproject.toml" enought ?
Yes in theory the Poetry files ("pyproject.toml" and "poetry.lock") should be sufficient.
And I also believe that the pipfile is not needed once we use Poetry, but I would appreciate the view of @bamthomas or @samuelrince or other with experience in Python... I feel a bit rusty ;-)
For clever-cloud deployment: If needed for clever-cloud deployment we should be able to generate the requirement.txt file on the fly. My understanding is that this deployment is done manually today. We should document (and maybe automate the entire clever cloud deployment via an action). @AirLoren , do you have some info about how it is done ?
For the serverless deployment: According to the docs of serverless framework, there is no impact if we remove the requirement.txt (the frameworks plugin supports Poetry if no requirement is found).
Indeed, I don't think we need the Pipfile anymore. To generate a requirements.txt
file, there is an official Poetry plugin.
Exacrly @demeringo it was just for the sake of migration and possible rollback but we should be done now :)
Ok i will take charge of :
Thanks for your feedbacks
Everything is available on dev branch.
Bug description
Since we use poetry for dependency management, requirement.txt file is desynchronized with actual project dependencies.
I suspect it leads to false alerts by depndendabots.
To Reproduce
Expected behavior
Either get rid of requirement.txt or keep it up to date by making poetry update it.
JSON OUTPUT
Additional context
Not sure if there is any purpose to keep the requirement.txt file or if it remains there only by accident / historical reasons as it was used before we started to use Poetry.
It may still be used by the serverless deployment (which does not work at the moment #153 , so I am not sure if we should get complely rid of it or relocate it to a dedicated repository).