startup tweaks and README additions #512
Conversation
moves examples and oembed into the intro section, which is focused on users who don't want to clone the repo consolidates movie details at the bottom so first-time users can focus on getting the server running
(1) adds the API credentials and key to the .env.template (2) creates get-api-key.sh (modeled after serve.sh) to request the API key and store it in .env (3) modifies the README accordingly
as in testRestApiExampleCode.py
I see now where these values are stored in package.json
There was a problem hiding this comment.
Thank you! This is the largest community contribution to RCVis, and I greatly appreciate it.
Most of these comments are pretty minor, including some questions about whether things were really required or just came up during the installation attempt.
The main question is around whether create-user.sh provides value over the UI solution -- I could be convinced it does, just want to hear your thoughts on it.
Thank you!
Co-authored-by: Armin Samii <[email protected]>
Co-authored-by: Armin Samii <[email protected]>
Co-authored-by: Armin Samii <[email protected]>
|
Thanks so much for your consideration. Most all of your flags and revisions make sense to me. The one lingering conceptual confusion concerns using the UI to make a new user when running locally. I struggled to do that without the |
|
Ah, so sorry! Did this work:
https://www.dropbox.com/s/fox65n97xj4vyb5/rcvis%20setup.mov?dl=0
…On Thu, Oct 17, 2024 at 6:31 PM Armin Samii ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In infra/.env.template
<#512 (comment)>:
> +
+# a user-generated string
+export RCVIS_SECRET_KEY=''
+
+# set to True to enable debug mode
+export RCVIS_DEBUG=True
+
+# host IP address
+export RCVIS_HOST=localhost
+
+# toggle offline mode
+export OFFLINE_MODE=True
+
+# credentials for local user in offline mode
+export OFFLINE_USERNAME=''
+export OFFLINE_PASSWORD=''
The dropbox link is missing -- can you try again to share it?
—
Reply to this email directly, view it on GitHub
<#512 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEB6N3NKQL27KHOVRYSBGDTZ4A3CZAVCNFSM6AAAAABP7JXP7GVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGNZWGQZTKMZUG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
I see. Given the number of manual steps (making the user, finding the link
in the terminal output, changing the link), I would propose that:
- credentials for the user be specified in .env
- serve.sh would (a) check for the existence of the user on launch (b)
create the user if not found
re:localhost -- I understand that in principle, but the link made
available in the terminal output (which is a convenient feature) won't work
without the local host specified explicitly in .env (as the video shows).
Perhaps there's a better (or more robust) way to launch it.
…On Thu, Oct 17, 2024 at 7:04 PM Armin Samii ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In infra/.env.template
<#512 (comment)>:
> +
+# a user-generated string
+export RCVIS_SECRET_KEY=''
+
+# set to True to enable debug mode
+export RCVIS_DEBUG=True
+
+# host IP address
+export RCVIS_HOST=localhost
+
+# toggle offline mode
+export OFFLINE_MODE=True
+
+# credentials for local user in offline mode
+export OFFLINE_USERNAME=''
+export OFFLINE_PASSWORD=''
Ah, the registration URL uses example.com because it doesn't know the
domain name. You need to replace example.com in the URL with localhost.
(BTW localhost:8000 and 127.0.0.1:8000 are the same -- you can just use
localhost to avoid having to change the settings.)
—
Reply to this email directly, view it on GitHub
<#512 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEB6N3NBK7JQ7ALT4PQTBG3Z4A66DAVCNFSM6AAAAABP7JXP7GVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGNZWGQ4DQNJUG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
That's a good suggestion! I'm realizing now that we're overlooking an important step though, which is that the first user should probably be an admin, not a regular user. For security reasons, I don't want to automate the creation of an admin account -- that should be explicit. I think the following will achieve your vision:
Thoughts? By the way -- if you prefer, I'm happy to punt the automation for a separate PR, and just have an instruction that says "run |
|
Either sounds good! You have a much clearer sense of the security risks.
My main goal is for the other volunteers to have a smooth on-ramp. My sense
is their motivation to stay involved may depend in part on how quickly they
feel productive, so I’d love to make the set up as smooth as we can and tee
them up for a quick win.
…On Sat, Oct 19, 2024 at 3:35 PM Armin Samii ***@***.***> wrote:
That's a good suggestion! I'm realizing now that we're overlooking an
important step though, which is that the first user should probably be an
admin, not a regular user.
For security reasons, I don't want to automate the creation of an admin
account -- that should be explicit.
I think the following will achieve your vision:
1. On ./serve.sh, checks for any admin account
2. If none exists, it runs python3 manage.py createsuperuser and
prompts you to enter a username and password
Thoughts?
By the way -- if you prefer, I'm happy to punt the automation for a
separate PR, and just have an instruction that says "run python3
manage.py createsuperuser on first launch" in the README.
—
Reply to this email directly, view it on GitHub
<#512 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEB6N3MXUQU3W27CMOOGJ4LZ4KX75AVCNFSM6AAAAABP7JXP7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRUGE3DKNZZGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
I took a swing at implementing your proposed approach:
Is it alright if we store the username (but not the password) in .env so it can check for the existence of a specific admin account? That's the approach I took here. If this implementation is alright by you, I think it's pretty straightforward now to go from out-of-the-box to uploading data. |
|
Perfect, thank you! One tiny final suggestion, and we are ready to merge. Really appreciate all the iterations here :) |
|
Wonderful. Thanks so much for your patience as I'm finding my feet!
…On Mon, Oct 21, 2024 at 8:16 AM Armin Samii ***@***.***> wrote:
Perfect, thank you! One tiny final suggestion, and we are ready to merge.
Really appreciate all the iterations here :)
—
Reply to this email directly, view it on GitHub
<#512 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEB6N3N3MKWZEXBDNJ7Y54DZ4TWDNAVCNFSM6AAAAABP7JXP7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRWGUYDOMZWGQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Just checking in on next steps with this PR. Is there more needed on my end to tie things up? I'm not sure I understand the continuous-integration/heroku check that's still pending. If there's some more I need to do, please let me know! |
|
Sorry for the silence!
|
startup tweaks and README additions (#512)
These changes address some of the frictions I encountered in getting started that I hope may ease the transition for other potential contributors.
The
install.shscript now initializes the users.envfile usinginfra/.env.template. I removed the corresponding snippet fromREADME. I added notes to the template about which parameters are needed for which basic functionality.I added a
create-user.shscript that contributors can execute before runningserve.shso they can upload data and generate visualizations.I reorganized the
READMEa little to present information in the order a first-time contributor may need it, moving advanced functionality (like movies) toward the bottom and set up details toward the top.I added missing
postregsqlandbotocorepackages I needed toREADMEandrequirements-core.txt.