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

Unify or seperate Python and Node parts #37

Closed
3 tasks
postfalk opened this issue Jan 13, 2023 · 1 comment
Closed
3 tasks

Unify or seperate Python and Node parts #37

postfalk opened this issue Jan 13, 2023 · 1 comment

Comments

@postfalk
Copy link

The presence of Python and Node in the same repo makes the creation of two test suites somewhat challenging. There are several possible solutions.

  • migrate ingest_zip to Python (would be my preference)
  • create two seperate repos
  • create a deeper directory structure where Python parts and Node parts are separated out on the repo top level.
@nathanielrindlaub
Copy link
Member

Takeaways after talking with @ingalls and @postfalk yesterday:

Animl code is predominantly written in Node and JS, and really the only reason we're using Python at all in the ingestion step is b/c getting exiftool to run in a Node Lambda runtime proved difficult (sadly this very promising node wrapper for it exiftool-vendored doesn't work in Lambda environments - go to the closed issues section of its repo and search for "Lambda" to learn why). So generally speaking, we are in agreement that we should continue to stick to Node by default and use it whenever possible.

Nick did his best to isolate the Python and Node code (option 3, above) but quirks of the Serverless Framework, however, are preventing us from completely separating the Python (ingest-image) and Node (ingest-zip) code bases into isolated directories because Serverless requires that the requirements.txt file exists at the root level. Moving away from Serverless is a goal (#26), so we're happy to scrap that and shift over to CloudFormation templates regardless but that would also allow us to better separate the Python and Node parts of the code. @postfalk is exploring that now and evaluating whether we can simply cleave off the EXIF data extraction into it's own self-contained service written in Python.

For the time-being, however, we're going to stick with this multi-language mono-repo approach, so closing this out for now.

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

No branches or pull requests

2 participants