The current way we're managing dependencies in our requirements.txt file is creating some issues since it requires all contributors to have a production environment ready locally before they can get started.
For example, we currently use SQLite in development and Postgres in production, but because psycopg2 is in our requirements.txt file new contributors are discovering that they need to have Postgres installed before they can continue forward (see #22 as an example of this).
This creates an unnecessary barrier to entry and makes the contribution process more difficult than it needs to be.
I propose we begin to fix this by:
Verifying the specific packages the application directly depends on
Breaking up the current requirements.txt into base, production, and potentially dev specific requirements files (which will help simplify getting a dev environment set up for new contributors).
Ensuring that we're only declaring our project's direct dependencies and allowing pip to handle dependency resolution for sub-dependencies
The current way we're managing dependencies in our
requirements.txt
file is creating some issues since it requires all contributors to have a production environment ready locally before they can get started.For example, we currently use SQLite in development and Postgres in production, but because
psycopg2
is in ourrequirements.txt
file new contributors are discovering that they need to have Postgres installed before they can continue forward (see #22 as an example of this).This creates an unnecessary barrier to entry and makes the contribution process more difficult than it needs to be.
I propose we begin to fix this by:
requirements.txt
into base, production, and potentially dev specific requirements files (which will help simplify getting a dev environment set up for new contributors).