Open questions

[ehmatthes]

This project is still in the pre-1.0 phase, so there are a number of broad goals:

• Refine a stable API that we can commit to for the entire 1.0 release cycle.
• Support a stable, reliable configuration and deployment process for Fly.io, Platform.sh, and Heroku.
• Include clear, thorough documentation and CLI messages.
• Make any architectural changes that would support long-term development. (This is nice, but not critical unless it addresses backward-incompatible changes.)

Please share any and all feedback and questions you have about these issues at this point.

[tataraba]

How are user accounts going to be handled? Suppose, for example, that a user has two accounts for a particular platform. Is there a way to expose to the user what account is being used? Should there be a way for a user to change what account is being used?

[ehmatthes]

That's a great question. My current approach has been to show the information we find, and when appropriate get confirmation that it's okay to proceed. For example when deploying to platform.sh, we need to know the user's organization that the app will be associated with. You can see the code that confirms it's okay to use this org.

I don't currently confirm the user's login name for any platforms, just validate that they are logged into the CLI for that platform.

I opened #153 so people can see the kinds of output that simple_deploy generates for various usages.

[jerivas]

As a first-time user of the project my main question is around the --automate-all flag. On a first glance I'm not sure what all means, that is, which parts would I need to execute manually later. I wonder if we can pass additional flags or think about using subcommands like these:

./manage.py simple_deploy prepare # Or configure, bootstrap, setup, etc. This changes the project files
./manage.py simple_deploy deploy # This actually connects to the platform and deploys
./mange.py simple_deploy all # Just runs `prepare` and `deploy`

[jerivas]

Those don't need to be subcommands BTW, they can stay as flags. Just need a clearer way to communicate what each option does

[jerivas]

Another idea is aligning more with Django's CLI conventions, namely:

• Use --verbosity to control verbosity or suppress output entirely
• Use --noinput|no-input to suppress prompting

[ehmatthes]

Yes, I really like this. See #154.

[jerivas]

Regarding docs, I was thrown off by the README because it links to the old CONTRIBUTING file and that mentions an additional sample repo that is no longer available. I now see that the samples live in the same repo so the contributing docs just need to be updated accordingly. Maybe consider leaving the old_docs folder in a branch, removing it from main, and using minimal versions of README and CONTRIBUTING that just point to RTD to do the heavy lifting.

[ehmatthes]

Sorry about that; #138 covers removal of old_docs/.

[leetrout]

👋 Would love to help out with logging / CLI message reporting or any other under-the-hood boring bits.

Is all the conversation taking place here in GitHub discussions? Or is there a community slack / discord?

[ehmatthes]

All of the conversation is currently here, on discussions and issues. I plan to keep it here until there's enough consistent activity to justify a slack/discord.

[glasnt]

There's currently three platforms, but when new platforms are introduced, what's the minimum set of features they should have?

Obviously having a deployed site is one thing, but it's a bit more than that.

As an attempt at a list, splitting into "Prerequisite" steps, "Automatic" steps, and post deploy "Descriptions", a platform implementation should:

• Prereq an account on the platform that can deploy things (may require billing)
• Automatically create a database
• Automatically deploy the project
• Automatically apply database migrations
• Automatically collect static
• Describe how to create a Django admin user
• Describe how to do other management tasks

[ehmatthes]

Hi again. I will respond to this fully once I finish #168, which is almost finished.

[ehmatthes]

Hi, everyone at home was sick last week so it took a little time to get back to this.

I just made an issue template for supporting a new platform. If everything there looks reasonable, please go ahead and fill it out and I'll respond there. If you have any questions, feel free to leave some pieces blank and add a comment with any questions, or ask here. At this point email is fine as well, although I'd rather have these conversations in public.

It's a little early to add support for another platform, but most issues with that would probably be balanced by having another (experienced) set of eyes on the internals of the project.