My rough plan following this diff is basically:

• Switch up how we're doing page rendering since that's kind of murky current in terms of how we distinguish between 'build a sanitized HTML element' and 'render a specific page'. That can be cleaned up pretty easily and it's probably best to do that now while the codebase is still small
• Build out the UI for the initial user registration flow. I think this will be the same deal as for a generic user registration, just with a 'this user is an admin' flag toggled
• Build out some infrastructure around password management and credential checking. This'll be a "fun" learning adventure for me.
• Build out the ORM piece so we can actually register a user and store their info to the database
• Profit???

working redirect

This implementation is also wrong atm. Properly, I'll need to use some flask wrapper function for this since __init__ by definition can't actually return anything (the implication being that, short of raising an exception, we can't interrupt the normal course of action and say, "Return page Y instead of page X"). I'll fix this in a subsequent diff.

Redirect to the appropriate registration route

Super basic check to see if at least 1 admin account has been registered yet

So I think that for now we might want to keep the view and route folders separate, where view is more or less "How do we bring together all of the UI components on the page" and route is "What Python gets run when we go to a URL". It looks like you have all of the blueprint routing in view currently.

Address review feedback

In D23#553, @brooke wrote:

@chris, maybe I should buy a mac this week.

Updates after rebasing

• Properly handle nested arguments

Whoops! Sorry, almost forgot: mind fixing the PEP lint issues also?

Looking good! Couple minor comments here and there.

Removed an extra debug statement

fleshed out implementation

Correct a bunch of silly class stuff

Fix an import issue

@brooke --- I kind of went to town on imports in this diff. It's all just cosmetic stuff, so go ahead and ignore that when looking at the SimplexConfigSource stuff

Just go ham on the imports

Unbreak some imports

@brooke — I'll need you to:

In D13#297, @brooke wrote:

$ arc land
Landing current branch 'tmp'.
TARGET Landing onto "dev", selected by "arc.land.onto.default" configuration.
REMOTE Using remote "origin", the default remote under git.
FETCH Fetching origin/dev...
Authenticated to phabricator.tbmh.org ([50.116.49.41]:2222).
Transferred: sent 2812, received 3052 bytes, in 0.6 seconds
Bytes per second: sent 4425.4, received 4803.1
This commit will be landed:

• a494ef1 rebase

Usage Exception: arc can not identify which revision exists on branch 'tmp'. Update the revision with recent changes to synchronize the branch name and hashes, or use 'arc amend' to amend the commit message at HEAD, or use '--revision <id>' to select a revision explicitly.

weird. Just git rebase --skip

Could you move this most recent commit into its own code review? I think things are going to get too messy here otherwise. Thanks!

Correct some SQL stuffs

In D12#258, @chris wrote:

I think approximate next steps from here will be to:
[...]

Couple more super minor comments, then you're good to go!

I think approximate next steps from here will be to:

• Add a global check that the database is reachable per credentials stored in an arbitrary config file
• If unreachable, redirect to an error page that prompts the user to run some config command. E.g., config set mysql.port=3306 or whatever else
  • Ideally, this should do a somewhat comprehensive check so that the instance admin has a fairly complete list of all required setup steps in one view (as opposed to having to continually reload the page to find the next broken thing in a hellish and neverending game of whack-a-mole)
• If reachable, check that all of the quickstart scripts have run. I need to figure out a way to do this efficiently and how to extend it to arbitrary patches delivered from the upstream
  • If not, run the quickstart scripts. Ideally with some error handling. But if not, I'd be okay with that for the short term (I mean, not really, but I'm just lazy)
• If everything's good so far, actually go ahead and render the page

Working implementation

Fixed copy/paste thingy