Conversation
8c410d4 to
ea63f51
Compare
chosak
left a comment
There was a problem hiding this comment.
At a high level, what does this reorganization get us? I get that it gives us SHAs for the packages we install, but what benefit does that provide over the already-pinned version numbers?
Did you look at using pyproject.toml instead, as documented here? That would avoid the need to have so many files floating around.
I do like the collapsing of django.txt and wagtail.txt into the regular requirements file.
The big thing it gets us is dependency resolution with failures when a conflict happens. We get to specify our direct requirements in the |
|
Snyk will fail on this PR until we update the requirements files in Snyk. When I have an approval I'll do that, before merging. |
chosak
left a comment
There was a problem hiding this comment.
At a high level, renaming deployment.txt to prod.txt feels potentially confusing to me since we use that set of deployment requirements for non-production environments. Can we leave it as deployment.txt?
It'd also be nice to have some kind of automation around keeping the .in/.txt files synchronized. I didn't see any obvious mechanism for this in the bedrock repo, so perhaps this hasn't been an issue for them.
There was a problem hiding this comment.
The create_research_report.groovy file in our internal Jenkins job repo references this file. I don't know if/how that job is being run but it will need to be updated if this file is going away.
There was a problem hiding this comment.
Yes, there are a few separate updates that need to be made. I was waiting to see if this even makes sense.
| # Install python requirements | ||
| COPY requirements requirements | ||
| RUN cp -Rfp /build/* /usr/local && rm -Rf /build && pip install -r requirements/local.txt | ||
| RUN cp -Rfp /build/* /usr/local && rm -Rf /build && pip install -r requirements/prod.txt |
There was a problem hiding this comment.
It seems like prod.txt is being installed twice now?
| #!/bin/bash | ||
|
|
||
| # ========================================================================== | ||
| # Import data from a gzipped dump. Provide the filename as the first arg. |
| - `prod.in`: requirements for deployment to production and other servers | ||
| - `test.in`: requirements for executing Python tests locally or in CI | ||
| - `dev.in`: requirements for development work, running, and testing | ||
| - `docs.in`: requirements to build the consumerfinance.gov docs. | ||
| - `scripts.in`: Requirements for running our smoke test and alert polling scripts without having to install all the other requirements. |
There was a problem hiding this comment.
Super nitpicky: inconsistent use of periods for these bullets.
| - `wagtail.txt`: specifies Wagtail version. In its own file to make it easier to test multiple versions, same as with `django.txt`. | ||
| - `prod.in`: requirements for deployment to production and other servers | ||
| - `test.in`: requirements for executing Python tests locally or in CI | ||
| - `dev.in`: requirements for development work, running, and testing |
There was a problem hiding this comment.
This says "testing" but isn't that what test.in is for?
I renamed it because I've switched the order of inheritance around a bit. I can rename it, but I don't feel like |
|
As next steps here, I'm going to work on:
|
74128b0 to
9db5398
Compare
I'm not going to do this for now. I like the idea of organizing the dependencies in a single location, but there doesn't seem to be a way to use pyproject.toml without accidentally making this technically python packageable, which could... introduce a lot of unexpected weirdness without a lot more work. |
|
It's not entirely clear to me why both Whereas the So, this looks like What I don't understand is why |
|
|
||
| These satellite apps are imported into consumerfinance.gov as part of the project | ||
| [requirements files](https://github.com/cfpb/consumerfinance.gov/blob/main/requirements/libraries.txt). | ||
| [requirements files](https://github.com/cfpb/consumerfinance.gov/blob/main/requirements/deployment.txt). |
There was a problem hiding this comment.
Should this point to deployment.in instead?
| @@ -16,7 +16,7 @@ We have six satellite apps that are maintained outside of the consumerfinance.go | |||
| - [teachers-digital-platform](https://github.com/cfpb/teachers-digital-platform) | |||
There was a problem hiding this comment.
I don't think I can let you get away with editing this file without correcting this part above 😄 TDP is no longer a satellite app, neither is ccdb5-ui, so we only have two satellite apps now, not 2.
| The standard [installation](../installation/) process for consumerfinance.gov | ||
| includes whatever versions of these packages are specified in project | ||
| [requirements files](https://github.com/cfpb/consumerfinance.gov/blob/main/requirements/libraries.txt). | ||
| [requirements files](https://github.com/cfpb/consumerfinance.gov/blob/main/requirements/deployment.txt). |
| django==3.2.23 | ||
| wagtail==4.2.4 | ||
|
|
There was a problem hiding this comment.
Should we consider merging these into the main list for simplicity? I get that these are the two biggies but we also have things like elasticsearch which are also pretty big...
| govdelivery==1.4.0 | ||
| Jinja2==3.1.2 | ||
| lxml==4.9.1 | ||
| newrelic==8.5.0 |
There was a problem hiding this comment.
Merging this into the main list of requirements necessitates rewriting this part of the docs.
This change is to simplify our Python dependency specifications and to use [pip-tools](https://pypi.org/project/pip-tools/#description)'s `pip-compile` to generate hashed requirements files with the full dependency tree from input files. This also performs dependency resolution and will highlight any conflicting versions. The model for this is that of [Mozilla's Bedrock project, the Django project that serves mozilla.org](https://github.com/mozilla/bedrock). The new file structure is as follows: - `deployment.in`: requirements for deployment to production and other servers - `test.in`: requirements for executing Python tests locally or in CI - `dev.in`: requirements for development work, running, and testing - `docs.txt`: requirements to build the consumerfinance.gov docs. - `scripts.txt`: Requirements for running certain jobs on Jenkins, so scripts can run in Jenkins without having to install all the other requirements. The contents of `base.txt`, `django.txt`, `wagtail.txt`, and `libraries.txt` move into `deployment.in`, which contains the minimum necessary to run consumerfinance.gov. `test.in` includes tools like `coverage`, `diff_cover`, and `tox` that are required to run our Python tests. `docs.in` and `scripts.in` are relatively unchanged, and `dev.in` combines all of the above to construct a local environment. These relationships between files now look like this: ```mermaid flowchart TD deployment.in test.in dev.in docs.in scripts.in deployment.in --> dev.in test.in --> dev.in scripts.in --> dev.in ``` Where previously they looked like this: ```mermaid flowchart TD ci.txt docs.txt base.txt deployment.txt django.txt libraries.txt local.txt wagtail.txt scripts.txt test.txt django.txt --> base.txt wagtail.txt --> base.txt libraries.txt --> base.txt base.txt --> deployment.txt base.txt --> local.txt ```
Update tox more
This will check that our requirements are appropriately compiled.
What needs to change here? |
This change updates our New Relic docs to remove information that is no longer valid. It's not clear to me that this entire section is particularly useful to document here though.
My bad - I must have been confused about which files were staying and which were going. Belay that comment. |
This change is to simplify our Python dependency specifications and to use pip-tools's
pip-compileto generate hashed requirements files with the full dependency tree from input files. This also performs dependency resolution and will highlight any conflicting versions. The model for this is that of Mozilla's Bedrock project, the Django project that serves mozilla.org.The new file structure is as follows:
deployment.in: requirements to run consumerfinance.gov in any environmenttest.in: requirements for executing Python tests locally or in CIdev.in: requirements for development work, running, and testingdocs.txt: requirements to build the consumerfinance.gov docs.scripts.txt: Requirements for running certain jobs on Jenkins, so scripts can run in Jenkins without having to install all the other requirements.The contents of
base.txt,django.txt,wagtail.txt, andlibraries.txtmove intodeployment.in, which contains the minimum necessary to run consumerfinance.gov.test.inincludes tools likecoverage,diff_cover, andtoxthat are required to run our Python tests.docs.inandscripts.inare relatively unchanged, anddev.incombines all of the above to construct a local environment.These relationships between files now look like this:
flowchart TD deployment.in test.in dev.in scripts.in docs.in deployment.in --> dev.in test.in --> dev.in scripts.in --> dev.inWhere previously they looked like this:
flowchart TD ci.txt docs.txt base.txt deployment.txt django.txt libraries.txt local.txt wagtail.txt scripts.txt test.txt django.txt --> base.txt wagtail.txt --> base.txt libraries.txt --> base.txt base.txt --> deployment.txt base.txt --> local.txtNotes and todos
If this approach is okay @chosak and anyone else who wants to review:
./compile-requirements.sh.Checklist