Pulp

PR: https://github.com/pulp/pulpcore/pull/445

IIRC, we previously had a command like this and then we removed it because we determined it wasn't adding value. Unless we are creating new value on top of Django, we wanted users to use the Django facilities directly.

Let me recap my understanding of this issue. Is it specifically for Pulp2 system-wide installs with Pulp3 system-wide install on top of that? I think most installs won't have this issue because Pulp3 installations on top of Pulp2 are expected to install together without issue because the pulp3 will be in a different virtualenv thus avoiding the pathing conflict.

Is your Pulp3 being packaged into a virutalenv?

While I think the packaging conflict is a good reason, let me try to expand on where this can add value overall. For the record, Justin pointed this aspect out to me.

To run any django-admin command you have to specify two environment variables (DJANGO_SETTINGS_MODULE and PULP_SETTINGS) every time. This can be both easy to forgot and tedious to export everytime. The benefit of a pulpcore-admin would be setting this configuration values for the user making it easier to run different admin commands within pulpcore context for debugging or sysadmin purposes.

bmbouter: yes, this is about system-pulp2 and system-pulp3 from RPMs, something you don't officially recommend, but what was the easiest path forward when it came to deploying pulp3 via rpm.

@ehelms: pulpcore already has a manage.py that will load the right settings, it's just not installed as a binary and not referenced anywhere in the documentation that only points to "django-admin"

I think one benefit I see here is: we'll definitely have to use something else than "django-admin" in Katello/RPM land, and having Pulp upstream having the same command documented, would be beneficial for consistency.

Oh, btw, I think the docs never mention you need to set DJANGO_SETTINGS_MODULE=pulpcore.app.settings (they only talk about PULP_SETTINGS), but w/o DJANGO_SETTINGS_MODULE, nothing will read PULP_SETTINGS?

We used to provide a similar wrapper around django-admin to pulp 3. However, we removed it because it did not support tab completion - which is a nice feature of using django-admin directly. Is there a simple way to make that work?

Here is the original ticket to remove pulp-manager[0].

[0] https://pulp.plan.io/issues/4450

Thanks for providing the old ticket.

Yeah, one should be able to teach bash/zsh that "pulp-manager"/"pulpcore-admin" should use the same tab completion helper as "django-admin".

If that's the only blocker you see to get that in, I can research that.

The blocker for me on this is that we're making a user change, but there isn't a user, use-case driving that change (outside of packaging). Packaging matters to me, so I don't mean to discount that. One option is to motivate the change via a use case for users, but since we didn't start there that seems unlikely. The other option is to apply a packaging workaround.

@evgeni I also value your experience as a packager, so I don't want to make that a frustrating experience either.

What packaging workaround options are possible in this situation?

we currently rename django-admin to python3-django-admin (https://github.com/theforeman/foreman-packaging/blob/37558e583e65819adb125942a3683785922004f0/packages/pulpcore/python-django/python-django.spec#L49-L50) and we'll have to do that in any case (as long as we want co-installation with pulp2).

we also adjusted the foreman/katello installer to use that name too (https://github.com/theforeman/puppet-pulpcore/pull/48).

thus, if I look only at the katello experience, "we're done" ;)

but if I look at the broader community experience, we notice that katello users now cannot follow Pulp upstream docs, as those mention "django-admin" which would lead to pulp2's django, not pulp3's django in the katello world. and vice versa, pulpcore users won't be able to follow documentation (forum/blog posts, whatsoever) that is targeted at katello.

I think this is the only user use-case I can provide you (besides the "don't need to set DJANGO_SETTINGS" above, which is quite low, granted).

What should we call it: pulp-django-admin or another name?

If we want users to know that the command is a wrapper for django-admin (and expose that implementation) then pulp-django-admin makes sense. Otherwise, we could use the name we had before, pulp-manage.

Also, do you plan to include auto-completion support with this ticket since users will otherwise lose that when we create the wrapper?

I do think we want auto-complete but I'm fine if we want to handle that later/separately.

It's nice how this came back to my original proposal ;-)

How do you use/enable bash completion today? A mere `pip install django` does not install any completion for me.

As for naming: Pulp2 has pulp-manage-db, so maybe pulp-manage would be close/confusing? How about pulpcore-manage or pulpcore-admin?

Installing Django's bash completion as documented in https://github.com/django/django/blob/stable/2.2.x/extras/django_bash_completion

and then doing a

complete -F _django_completion -o default pulpcore-admin

and having a valid PULP_SETTINGS makes the completion work for me :)

evgeni wrote:

Installing Django's bash completion as documented in https://github.com/django/django/blob/stable/2.2.x/extras/django_bash_completion

Sweet! Let's use that.

and then doing a [...] and having a valid PULP_SETTINGS makes the completion work for me :)

We still won't set PULP_SETTINGS in here, I wrote some about that in this comment here

bmbouter, my question "how do you enable completion for django-admin" still stands, as this is not documented :)

The state of this issue and comments are rather confusing, so let me summarize what I'm seeing and check to see if we're all on the same page.

1) We do want to add a wrapper. What name do we prefer?
- pulp-manage (+1'd by several folks in the comments though not quite what we had before, -1'd as being too close to pulp-manage-db from pulp2 and potentially confusing)
- pulp-manager (what we had before)
- pulp-django-admin
- pulpcore-admin

2) We do want to provide autocomplete in this same ticket. Do we know how to do that?
- evgeni linked to django_bash_completion page in comment #20 but then in #22 says this functionality is not documented

Does evgeni's PR need to be reviewed/merged once we reach consensus on these final items?

CodeHeeler, yeah, that is also my perception of the state:
1) we want a wrapper, but didn't decide on the name yet
2) having completion was raised as a PRO for not having an own wrapper, which I understand, but I also don't see completion working for users when they just follow the current docs.

as to my PR: it solves 1, minus the right naming, but fixing that is cheap as soon as we have agreed on one.

+1 to pulp-manage or pulp-manager

I feel like auto-completion could be a separate ticket but I'm also happy if we add it now.

+1 to this.

I just did some testing myself, by using a modified completions file:

[mdepaulo@mdepaulo ~]$ diff -u /usr/share/bash-completion/completions/django-admin ~/completions/pulp-django-admin 
--- /usr/share/bash-completion/completions/django-admin	2019-12-18 03:28:06.000000000 -0500
+++ /home/mdepaulo/completions/pulp-django-admin	2020-02-13 16:26:56.627202013 -0500
@@ -37,7 +37,7 @@
                    COMP_CWORD=$COMP_CWORD \
                    DJANGO_AUTO_COMPLETE=1 $1 ) )
 }
-complete -F _django_completion -o default django-admin.py manage.py django-admin
+complete -F _django_completion -o default django-admin.py manage.py pulp-django-admin
 
 _python_django_completion()
 {

@evgeni, it's provided by a yum package called python-django-bash-completion:

https://github.com/pulp/ansible-pulp/blob/2ec2a7091358b5bcd5d1b912522279ab6ab959a9/roles/pulp-devel/tasks/install_basic_packages.yml#L57