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

Make default debug settings runable #20

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

MyPyDavid
Copy link
Member

No description provided.

…tings

Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
@jochenklar
Copy link
Member

Do we need this? I had a similar idea a year ago or so and then thought that development setups will differ anyway. I ended up creating my own dev app (https://github.com/jochenklar/rdmo-dev/blob/main/rdmo_dev/settings.py), which I include in my local.py.

I will also switch of DEBUG in development now and then and use postgres all the time.

What we could do, is to ship the devlopment.py by default, but this depends on what concrete problem you actually want to solve.

@jochenklar
Copy link
Member

What I usually do for "my" RDMO instances nowadays is to create:

config/settings/environments/development.py
config/settings/environments/production.py

with the different setups, and copy them to config/settings/local.py or link them and use https://github.com/AGWA/git-crypt to encrypt the files (which I would not suggest for the beginner setup).

@jochenklar
Copy link
Member

We could do the same here (not the crypt stuff) and remove config/settings/sample.local.py which I never liked anyway. But maybe we should discuss this on Zoom.

@MyPyDavid
Copy link
Member Author

Yeah, the main problem, from the experience of the last hackathon(s), is that when new users/developers want to start up the rdmo-app it can take a lot of time (and effort) following all the steps in the development docs to get the runserver to run.

I think that the easier Dev Experience would be to just have it to run (with minimal configuration effort after cloning) and start working/changing things from there. For deployment it will always be different and has to be adjusted anyways.

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