[Django] #31458: Allow changing executable_name for dbshell management command
Django
-------------------------------------+-------------------------------------
Reporter: minusf | Owner: nobody
Type: New | Status: new
feature |
Component: Core | Version: 3.0
(Management commands) |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 1
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 1
UI/UX: 0 |
-------------------------------------+-------------------------------------
This is a proof of concept to make the dbshell executable configurable
either in `settings.py` (`DBSHELL_EXECUTABLE`) or through an environment
variable (`DJANGO_DBSHELL_EXECUTABLE`). The new executable must accept
the same command line parameters.
If there is interest in this, i'll be happy to provide the bits for the
other backends and the documentation.
`$ DJANGO_DBSHELL_EXECUTABLE=pgcli python manage.py dbshell`
https://github.com/django/django/pull/12709
--
Ticket URL: <https://code.djangoproject.com/ticket/31458>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: minusf | Owner: nobody
Component: Core (Management | Version: 3.0
commands) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
Changes (by felixxm):
* status: new => closed
* resolution: => wontfix
* easy: 1 => 0
Comment:
I don't think that `dbshell` should support or respect different
executable names, this can create a bunch of issues. You can always use
different command by aliasing at system level or by
[https://docs.djangoproject.com/en/3.0/ref/databases/#subclassing-the-
built-in-database-backends subclassing the built-in database backends].
--
Ticket URL: <https://code.djangoproject.com/ticket/31458#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: minusf | Owner: nobody
Component: Core (Management | Version: 3.0
commands) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
Comment (by minusf):
just out of curiosity, could you list some of those issues?
--
Ticket URL: <https://code.djangoproject.com/ticket/31458#comment:2>
Django
-------------------------------------+-------------------------------------
Reporter: minusf | Owner: nobody
Component: Core (Management | Version: 3.0
commands) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
Comment (by felixxm):
For example inconsistency with supported arguments. I don't think we
should maintain this and as I described above folks can use different
executables if they really need to.
--
Ticket URL: <https://code.djangoproject.com/ticket/31458#comment:3>
Django
-------------------------------------+-------------------------------------
Reporter: minusf | Owner: nobody
Component: Core (Management | Version: 3.0
commands) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
Comment (by minusf):
sure, while it's not much code to add, it's a fairly niche itch to scratch
i agree.
but your comment implies that this has numerous "potential issues" and the
only one you can come up with is the one that the PR makes clear: only
dropin replacements would be supported that take exactly the same command
line arguments (which most "upgraded" shells always do).
Are there any other issues besides "do your customisation at home"?
--
Ticket URL: <https://code.djangoproject.com/ticket/31458#comment:4>
Django
-------------------------------------+-------------------------------------
Reporter: minusf | Owner: nobody
Component: Core (Management | Version: 3.0
commands) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
Comment (by felixxm):
I said "**can** create". It's not only about arguments but also about
respecting environment variables.
You can start a discussion on DevelopersMailingList if you don't agree.
--
Ticket URL: <https://code.djangoproject.com/ticket/31458#comment:5>
Django
-------------------------------------+-------------------------------------
Reporter: minusf | Owner: nobody
Component: Core (Management | Version: 3.0
commands) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
Comment (by minusf):
nah, it's fine. i think it could be a better addition to `django-
extensions`. thank you for looking into it.
--
Ticket URL: <https://code.djangoproject.com/ticket/31458#comment:6>
Django
Reporter: minusf | Owner: nobody
Component: Core (Management | Version: 3.0
commands) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
-------------------------------------+-------------------------------------
I would like to see this reconsidered; macOS homebrew postgresql CLIs are
installed using a version suffix -- for example, `psql-17` for pg 17 --
which immediately renders the dbshell command useless when doing local
development. Given there's no mechanism to change the command, I can't use
this otherwise very helpful tool.
I understand I can ignore the helper command and run psql-17 myself, but
it feels like a reasonable thing to support for Django
--
Ticket URL: <https://code.djangoproject.com/ticket/31458#comment:7>