| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
@dhermes can you fix the conflicts? |
Sorry, something went wrong.
Using boilerplate code snippet in each setup.py to load the requirements.txt and adding the requirements.txt file to MANIFEST.in file.
There was a problem hiding this comment.
I am -1 on the "parse requirements.txt" approach:
I believe we would be better off leaving install_requires as the definitive version spec for the library, and using the pkg_resources API in our scripts to get the dependency metadata we need.
/cc @jonparrott
Sorry, something went wrong.
|
@tseaver SGTM. @jonparrott and I discussed and I view pkg_resources as inferior to parsing because it requires having those packages installed somewhere before we decide we want to run those tests. I'll whip up a proof of concept that parses our setup.py files, assuming some kind of format, and enforces the assumptions with errors. |
Sorry, something went wrong.
|
@dhermes To do the analysis on Travis, we are going to have them installed somewhere, likely into a tox environment. If we add a console_script (maybe as an extra) which is installed into the environment, then we can get the metadata from it. |
Sorry, something went wrong.
Sorry, something went wrong.
Co-authored-by: Victor Chudnovsky <vchudnov@google.com> Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
feat: update image to us-central1-docker.pkg.dev/cloud-sdk-librarian-prod/images-prod/python-librarian-generator@sha256:160860d189ff1c2f7515638478823712fa5b243e27ccc33a2728669fa1e2ed0c
| Back | FazBrowse Home | New Git URL |
To make computing the dependency graph easier I moved the requirements of each package into a requirements.txt file.
I'm happy to instead write a custom setup.py parser but decided that the route of less code was "better" in some sense.