-
-
Notifications
You must be signed in to change notification settings - Fork 5
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
Describe App #18
Comments
Summarizing from #15 (comment).
|
@rickmanelius I disagree about discarding the db credentials (#18 (comment)). Those are there for anybody who is doing an install, and an install is a normal thing to do. |
Hi @rfay. To be clear, I'm not suggesting we remove this section:
What I intended was the instructions to login to the mysql container directly. Specifically this portion:
The first portion is absolutely beneficial for doing a site install. The second is more for someone wanting to login to the DB directly and someone using the UI, I would argue, is more likely going to click the link to the phpMyAdmin service. Let me know if that addresses your concern of if you feel strongly that both sets of DB credentials should still be surfaced! |
The most important part I was concerned about is db/db/db/db. However... there's no reason that a ddev-ui user would be less likely to use the external credentials (using 127.0.0.1 and port number). I agree they might be less likely to use the mysql command line, but they're perfectly likely to use another tool (like the many competitors to sequelpro). So the problem is probably that we focus the external credential part on the mysql client command-line tool instead of general instructions. |
But note @andrew-c-tran - the main credential section was not intended to be removed. |
understood, the command line instructions will be removed and the credential section will be added back in. One thing to think bout though is if we want to keep text parsing in to support older ddev cli versions, or if we want to enforce the next release of ddev cli that includes the json output to be the minimum version number? Due to the fragile nature of text parsing, i'm much more of a fan of enforcing a minimum version going forward |
Let's just support newer >=v0.9.4 ddev, IMO. You can do a I note that ddev version -j might need to be better for you. I don't like it much. It should give digestible info. |
i've updated the PR to use the json output from the CLI and have updated the tests accordingly. I've also opened #54 to address the version checking need as it's a common need for both ddev-list and ddev-describe functionality. |
merged #51 |
What happened (or feature request):
What you expected to happen:
End-users can access information from ddev describe.
The text was updated successfully, but these errors were encountered: