I'm sure your extreme DevOps expertise can find a way to automate the deployment of a pip package.
I mean, you are argument about manual step for an automatic step is a straw man. Let's say you make two deployment of your app. One on your system, one on premises on a customer system. You want both system to make use of a different set of user. But you want that idenpotent function to manage user on both system. Because that's part of your solution. You want to automate deploying your requirements.txt more than your set of user. Beside, these days, starting your pet Django feature as a third party project is the recommended way to go. You will be able to react more quickly to user demand while your feature mature and the Django project will be able to judge how useful is your project. Look at whitenoise or Django rest framework. And please, read the code of conduct one more time. No subscriber of this mailing list should have to read Neither this email nor your because we are acting like children, being all snarky and passive aggressive. On Oct 11, 2018 12:27, "Jamesie Pic" <j...@yourlabs.org> wrote: Sorry, I forgot to answer about the loaddata proposal. So, loaddata will not do user removal for one thing. About user creation, the process we have is: - add the user to the users list, - set the password in `ansible-vault create passwords/username` - CM will execute createsuperuser for users, >From that, it should maintain the userbase, on an ootb django project. The workflow you are suggesting is: - add the user to the users list, - set the password in `ansible-vault create passwords/username`, - somehow parse the settings to know the user model, - generate a json file with the users, and hope that it will work with their model, - use a script that django doesn't have to generate a salted password, - upload the script and apply it. I don't think I want my automation steps to rely on hope. What about the debugging process of such a complex implementation for such a simple task ? The cost is not worth the benefit. Injecting code in django-admin shell still does the same with a much cheaper complexity cost. Have a great day. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC6Op19o1wUCd4CSvxHLKHAdBduPOO4H6PuhtuyZc_LYBO9ooA%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CAC6Op19o1wUCd4CSvxHLKHAdBduPOO4H6PuhtuyZc_LYBO9ooA%40mail.gmail.com?utm_medium=email&utm_source=footer> . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEuG%2BTYjpMJna-QScxooaLkonR9ixdBr7oJSuHpa9EyM2gi5bQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
