Conversation
|
Having deleted all this code, are we now in a position to remove One thing we lose by removing the Camelot backend is the ability to have a "working" local application with out connecting it to AWS. That doesn't mean we should keep Camelot, but do you think there is any mileage in having a "mock" PDF parsing backend? I am thinking we write a "parser" where you feed it any PDF and it throws the PDF away and just returns the same hard-coded list of people/parties. Worth bothering with? There's a code formatting error to resolve with ruff to get the build passing. |
|
Quick thing I noticed while working on something else.. decorator on them. Can you double-check if that is something we can get rid of as part of this PR. |
02890ce to
a5b245d
Compare
a1af2ff to
e021841
Compare
|
I force pushed the commit where I removed too much code, restoring some files. This should mean we can merge with #2639 easier |
e021841 to
8424a2c
Compare
chris48s
left a comment
There was a problem hiding this comment.
I've left a few more comments.
Can you have a look at getting the build passing.
Also the comment about deleting candidates_import_from_live_site still stands
This was used to capture baselines for Camelot. We no longer need this code
9170df9 to
64a87e2
Compare
This is a bit of a tangle to remove cleanly. I think I've removed too much, especially some of the tests that really should be converted to use AWS Textract rather than just removing them. The plan is to built these up again with a bit of a rethink / redesign of the whole system. Maintaining these tests while refactoring wouldn't be a good idea, so I suggest revisiting them later.
Now we're in a container, we don't need to skip these tests
This hasn't been useful for a while and we now have a system to import from a DB backup
This was only used by Camelot and removing it should help us catch code paths that still try to use camelot
In this PR I do a couple of things:
A couple of extra points: