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

Dependency management for apps #8

Open
nikochiko opened this issue Sep 26, 2022 · 3 comments
Open

Dependency management for apps #8

nikochiko opened this issue Sep 26, 2022 · 3 comments

Comments

@nikochiko
Copy link
Contributor

Right now,

  1. Dependencies are not taken from the app's requirements.txt automatically
  2. If versions are not correctly specified in the requirements.txt file, apps will crash (they would crash even if it wasn't on hamr, but this happened before and we should take this case into accout while building for logs or writing documentation).
  3. There is no way to solve for version conflicts between different apps

Proposed solutions:

Separate site-packages/ for each app

We could install the dependencies for each app into a site-packages folder, and insert it into sys.path before getting the app.

Pros:

Cons:

  • There would be too much duplication of dependencies involved between apps. Even separate deployments of the same app would have copies of dependencies.

Single warehouse for dependencies, with symlinks to each app's site packages

This solves for the storage space problem in the eariler solution by keeping all python dependencies and their versions in a single location, and then symlinking specific versions into each app's site-packages directory.

Pros:

  • Saves space

Cons:

  • Might take some engineering effort to 1) arrange package directories into name/versions and 2) reading from requirements.txt and getting a suitable version (upgrading packages sometimes)

Notes

I think we could go with the first one for now, and then later when we start running out of storage, we can optimize.

This change would also affect the deployment flow. We would need to decide whether the POST request for deployment is kept alive while all the dependencies are installed, or if we give users a link to follow the deployment logs and status.

@anandology
Copy link
Member

Separate site-packages/ for each app

Why do you want to reinvent virtualenv?

This solves for the storage space problem...

When did storage space became a problem?

Also, hamr is not-only for python. We shouldn't try to build new abstractions for deploying python apps.

The problem statement could probably be:

Provide a way to manage application dependencies easily. That could work with any language. We may provide a default behavior for popular languages, but that doesn't stop anyone from installing their own dependencies.

Also, consider the following cases and see what does it take to deploy them on hamr.

  • a static website built with Jekyll
  • a static website built with hugo
  • docs with mkdocs
  • an app that requires installing a binary (for example: graphviz-api)

@anandology
Copy link
Member

Also, read about https://www.heroku.com/elements/buildpacks

@nikochiko
Copy link
Contributor Author

consider the following cases and see what does it take to deploy them on hamr

OK, that's a good angle to look at it. Thanks!

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

No branches or pull requests

2 participants