Skip to content
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

DTS manifest file part 1 #205

Open
wants to merge 12 commits into
base: develop
Choose a base branch
from
Open

DTS manifest file part 1 #205

wants to merge 12 commits into from

Conversation

briehl
Copy link
Member

@briehl briehl commented Nov 13, 2024

This includes the first steps toward having the DTS manifest files as import specifications. It does the following:

  1. Adds .json to the allowed import spec files, as DTS_MANIFEST
  2. Maps DTS_MANIFEST to a (for now) dummy parser function.
  3. Starts up the dummy parser function with basic fail conditions - file not found, file is a directory, file is wrong (basic) format, etc.

Next PR will make the parser do some parsing.

Copy link
Member

@MrCreosote MrCreosote left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's been so long I don't really remember how the mapping mechanism works

Comment on lines 106 to 107
DTS_MANIFEST: ["json"],
JSON: ["json"],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DTS_MANIFEST and JSON are both the text JSON and so collide in the map

@MrCreosote
Copy link
Member

Ugh, hit finish review too early. I'm not done

Copy link
Member

@MrCreosote MrCreosote left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Holding the review here as I think the app configuration is incorrect

Comment on lines 10 to 12
# Data Transfer Service Manifest format (which is a specific JSON format)
DTS_MANIFEST = "JSON"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These types are just the file types, regardless of the semantics of the type. Just JSON should be used here

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

{
"id": "import_specification",
"title": "Import Specification",
"app_weight": 1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is supposed to be autogenerated IIRC but I don't see any code changes that would cause this to be different

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC you need to update the mapping here:

file_format_to_app_mapping[JSON] = [escher_map_id]

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well that'd be real cool if that were documented anywhere. I'll add that and fix it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#96

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added some documentation to the README. Not perfect, but should be enough for now.

@briehl
Copy link
Member Author

briehl commented Nov 14, 2024

Ok, that was a very silly change I did.
New version:

  • Removed that DTS_MANIFEST mapping nonsense, just stick with JSON.
  • Ran GenerateMappings.py to update the mapping JSON file. Which really didn't change anything, but we should consider best practice.
  • Added some lightweight documentation on the file mapping stuff and how to update it. Should come back to that at some point.

@briehl
Copy link
Member Author

briehl commented Nov 14, 2024

Trivy's being whiny again: TOOMANYREQUESTS: retry-after: 483.512µs, allowed: 44000/minute"

@@ -120,7 +129,7 @@
fba_model_id,
import_specification,
]
file_format_to_app_mapping[JSON] = [escher_map_id]
file_format_to_app_mapping[JSON] = [escher_map_id, import_specification]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now I'm wondering if we should have a separate type in the dropdown for DTS manifests vs. import specifications. Maybe just DTS manifest? That would be forward compatible if we ever wanted to support standard import specifications with JSON input.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I thought of that. I guess that would be a trivial change, but I'm not sure the best thing to call it. I also wonder if it would be confusing to users at all? They'd have to read instructions on the whole DTS process anyway.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I take it back, that's not trivial at all. It means a narrative change at minimum, possibly an API change if we want to be really thorough. Maybe a new API endpoint?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would make it a query param probably

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just checking here - you're saying the separate type and query param is the way you're going to go?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, if it's going to work that way, there probably shouldn't be a JSON: dts_parser entry in the parser mapping

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is how it work right now, as of this PR, and everything else that's in it. A later PR that updates the endpoint to use a query param will probably undo this. Also, the Narrative will need to have a mapping of some sort, which is what this sets up. So it might not be from .json -> Import Specification, but it'll need to be something similar.

I don't want this to get more complicated and would like to keep that in a single PR with the bulk_specification endpoint change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough, as long as the plan is clear

staging_service/autodetect/Mappings.py Outdated Show resolved Hide resolved
Copy link

sonarcloud bot commented Nov 19, 2024

Copy link
Member

@MrCreosote MrCreosote left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM given the caveats re reworking this have have a specific DTS manifest type

@@ -0,0 +1,122 @@
{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem to match the documentation in individual_parsers but I assume the format is still changing

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

Successfully merging this pull request may close these issues.

2 participants