You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 22, 2020. It is now read-only.
As a follow-up to #199, we may need to re-evaluate the container structure. Currently, all services benefit from the caching, but only the docs service benefits from the added python requirements. Both the interface and prediction services wind up bloated with extra requirements they don't need.
Expected Behavior
The docs service should use caches provided by the interface and prediction services. However, neither the interface nor prediction services should have unnecessary python requirements.
when running docker-compose -f local.yml build on a clean system, the python requirements files should not be downloaded by documentation service.
when running docker-compose -f local.yml build on a clean system, the documentation service should use the caches provided by the prediction and interface services.
when running docker-compose -f local.yml build on a clean system, the prediction service should not install unnecessary interface python requirements such as Django.
when running docker-compose -f local.yml build on a clean system, the interface service should not install unnecessary prediction python requirements such as pytorch.
NOTE: All PRs must follow the standard PR checklist.
The text was updated successfully, but these errors were encountered:
I guess the docs service should still use the cache that was built by the interface service (instead of re-downloading all the Python dependencies)? Do you have any ideas how to accomplish that?
@WGierke so after thinking about this some more, we may need to re-evaluate the entire structure. Currently, all services benefit from the caching, but only the docs service benefits from the added python requirements. Both the interface and prediction services wind up bloated with extra requirements they don't need.
And I'm not sure if it's possible to satisfy both optimizations at once.
reubano
changed the title
Invert docker-compose interface service dependency
Rethink docker-compose dependencies
Nov 8, 2017
reubano
changed the title
Rethink docker-compose dependencies
Rethink docker-compose container dependencies
Nov 8, 2017
Overview
As a follow-up to #199, we may need to re-evaluate the container structure. Currently, all services benefit from the caching, but only the
docs
service benefits from the added python requirements. Both theinterface
andprediction
services wind up bloated with extra requirements they don't need.Expected Behavior
The
docs
service should use caches provided by theinterface
andprediction
services. However, neither theinterface
norprediction
services should have unnecessary python requirements.Technical details
Acceptance criteria
docker-compose -f local.yml build
on a clean system, the python requirements files should not be downloaded bydocumentation
service.docker-compose -f local.yml build
on a clean system, thedocumentation
service should use the caches provided by theprediction
andinterface
services.docker-compose -f local.yml build
on a clean system, theprediction
service should not install unnecessaryinterface
python requirements such asDjango
.docker-compose -f local.yml build
on a clean system, theinterface
service should not install unnecessaryprediction
python requirements such aspytorch
.NOTE: All PRs must follow the standard PR checklist.
The text was updated successfully, but these errors were encountered: