Django / Postgres example - need to move to it's own repo and update

[jfmatth]

Hi, Loving Piku!

I'm a Django / Postgres hobbiest and the example in the examples folder for Django / Postgres seems a little 'forced'. I like the idea of a single server option (i.e. PIKU and Postgres on same server) but I think the implementation needs modernizing.

A couple of things I will change in my example:

1. Change the settings.py to use dj_database_url, the 12-factor standard for Django.
2. Don't use release.sh to provision the DB, but assume it's there :)
3. Use config to set the DATABASE_URL variable and then run migrate and createsuperuser by hand like the example already

I'm happy to build the example repo, and it's README, just looking for guidance here on what the team normally likes to see. The goal would be for the example to be a platform for Django DB folks to start from (which is what I like).

Thoughts?

[jfmatth]

Ok, built a first version of the idea, tell me what you think.

I'm happy for you guys to bring it over to the PIKU org or give me PR's to fix stuff then move it over. Either way, fun to work on this.

https://github.com/jfmatth/sample-django-postgres.git

[chr15m]

Hi again @jfmatth! Thanks for your offer to make an updated example, that sounds great. I guess the choice of more vs. less manual intervention is a matter of taste. My personal taste falls on the side of having more scripted in the code and less manual steps (because I'm always forgetting to do manual things) but I am sure there are many others who like it the other way. How about if we make a new repository with your take on best-in-class Django deployment to Piku? Thanks for the reminder to move migrate into the release script.

[jfmatth]

Hi @chr15m I agree that scripting is good if it's repetitive , but in the case of Django and DB setup, I view that as a one-off exception).

[chr15m]

This looks good, thanks. I think we should rename my implementation to sample-django-postgres-minimal and make yours the new sample-django-postgres.

Re: repetitive, I find it surprising how often "one off" becomes something I have to do more than once. 😁

[jfmatth]

@chr15m - OK, so I took a closer look at your sample postgres one and made a new repo with something closer to what you're doing. I honestly didn't know a user could run postgres' createdb command and get themselves a DB, but makese total sense.

I moved a few things around, simplified the settings file, and updated to Django 4.x

Let me know what you think

https://github.com/jfmatth/piku-django4-postgres

[chr15m]

@jfmatth this looks great, thanks for providing an updated example. If it is ok with @rcarmo we can move your example to the piku organization, and you can make a PR to update the documentation to point to your example instead.

[chr15m]

@jfmatth one minor thing is the traditional capitalization is "Piku" not "PIKU" so it might make sense to update your README to reflect that. Not a huge deal or anything.

[chr15m]

@jfmatth one other minor thing is you could add the 'migrate' step to your ./bin/stage_release.sh or else maybe put a note for the user about how to run it remotely when they are ready, as you've done with the create-db.

[jfmatth]

@chr15m No worries, always glad to contribute.

You could either take the whole thing as an example repo for your org, or reference mine. Probably the former would be better, then you guys can own it and I can do PR's against it.

Dang it, I thought I put in the migrate command, but happy to add it after the above is decided. I don't like to migrate on every release, that seems too dangerous 😮

I

[jfmatth]

I do have 'migrate' in the stage_release.sh command, but should mention in the README how to it manually.

[jfmatth]

@chr15m Let me know after you pull it into your org, I have a few things I want to add like a DBNAME instead of using the NGINX_SERVER_NAME in the provision script. Some other 12-factor Django ideas Ill sprinkle in too.

[github-actions]

This issue is stale because it has been open for 90 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 30 days since being marked as stale.

[chr15m]

@jfmatth sorry I haven't got around to this yet. I don't understand what I am supposed to do here to give you access. Can you let me know how you want to proceed? Can I just give you write access to the Django example repository?

[jfmatth]

Hi @chr15m, Sure.

I was thinking you'd just bring the whole repo of mine into one of yours and either point to it in the docs or just leave it there like others.

I don't need access and would prefer just to use PR's to update it from time to time, if that's OK.

Hope this helps.

[github-actions]

This issue is stale because it has been open for 90 days with no activity.

[chr15m]

@jfmatth I checked the documentation and it seems you have to initiate this from your end. There's nothing I can actually do to bring it over I don't think.

https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository

Also:

To transfer a repository that you own to an organization, you must have permission to create a repository in the target organization.

And:

The original owner of the repository is added as a collaborator on the transferred repository. Other collaborators to the transferred repository remain intact.

I am fine with this myself as it would be less burden for you to maintain it, but need to check with @rcarmo.

[jfmatth]

HI @chr15m, thanks for keeping this alive 😄

I'll read the docs and initiate if that's what it takes. I want to do some clean up first and then ill give it a go.