У меня есть вопрос, как сгенерировать дампданные без этого txt при запуске:
[1mЗагрузка переменных окружения .env...[0m
Вот пример:
[1mLoading .env environment variables...[0m
[
{
"model": "auth.permission",
"pk": 1,
"fields": {
"name": "Can add permission",
"content_type": 1,
"codename": "add_permission"
}
},
....
Я не могу найти решение, это раздражает, потому что я хочу сделать скрипт sh
docker-compose exec django pipenv запустить python manage.py dumpdata --indent 2 > приспособления/test_dumpdata.json
Вероятно, в вашем коде есть оператор print, печатающий эту строку (вероятно, в ваших настройках), Django обычно не читает файлы .env. Кроме того, зачем вообще беспокоиться о перенаправлении вывода и т. д., Есть опция , чтобы указать, в какой файл должен идти вывод.
@Swift, ты говоришь о pipenv? Я не понимаю, с этим нужно использовать pipenv run. Или я вас не понял.
Вы установили pip env, так что да, вам это нужно, потому что это ваша конфигурация. Я говорю, как правило, если у вас есть контейнер докеров, вам не нужно настраивать pip env, а просто устанавливать пакеты в контейнеры докеров python.
@Swift, хорошо, но я не понимаю, почему это лучший вариант, чем pipenv, если я разрабатываю в этой среде. В этом варианте pipenv бесполезен, все говорят, что pipenv — это будущее. По вашему мнению, я должен установить только требования без pipfile?
@Keso Если вы хотите ответить на вопрос, опубликуйте его как ответ. Не редактируйте ответ в вопросе.
@AbdulAzizBarkat, я видел, что это обычный способ сделать это xD. извините, это мой первый вопрос, когда мне кто-то помог.
См. Могу ли я отредактировать свой вопрос, чтобы добавить ответ?





Как упоминалось в одном из комментариев, вы также можете полностью обойти использование перенаправления stdout, используя флаги -o или --output, указав действительный путь и имя файла в качестве параметра флагов. И в вашем случае это будет РЕКОМЕНДУЕМЫЙ способ сделать это.
Подробнее об этом в документах здесь: https://docs.djangoproject.com/en/4.1/ref/django-admin/#cmdoption-dumpdata-output
Кроме того, если вы просто хотите сделать это один раз, вы можете зайти в сам контейнер докеров.
Что происходит, так это запись stdout в указанный вами файл, но поскольку вы запускаете команду с хоста, в stdout появляется дополнительная информация от докера.
docker exec -it <container_name> bash
python manage.py dumpdata ...
Кроме того, в вашем конкретном случае вам нужно будет активировать виртуальную среду перед запуском dumpdata.
Кроме того, вы можете автоматизировать это, создав скрипт для сброса данных в контейнер докера и вызывая его с хоста, как вы делали это раньше (я полагаю, что в настоящее время я не могу проверить этот последний бит)
Помните, что если вы используете pipenv , вы ДОЛЖНЫ использовать pipenv run python manage.py ... Я вижу, что если я нахожусь внутри докера, ваш файл параметров генерируется без этого стандартного вывода, упомянутого в моем вопросе. Но написать sh-скрипт этим методом невозможно. Я не хочу сбрасывать данные каждый раз, когда запускаю docker-compose, поэтому я не понимаю вашу 4-ю строку. Я проверю ваше предложение с флагом -o. Если это сработает, я добавлю это в свой вопрос.
Моим первоначальным ответом было решение, которое вы можете вручную запустить в командной строке, чтобы получить желаемый результат. Обратите внимание, что моим рекомендуемым решением является флаг -o, так как он более явный.
Окей, я понимаю. Ваше решение правильное, но позвольте мне объяснить, что я сделал в вопросе редактирования. Большое спасибо, я поставлю вам оценку за ответ, но все, кто это читает, проверьте редактирование вопроса. Еще раз спасибо.
Спасибо за Свифт. Для этого я использовал флаг -o с выходным путем.
Вот сделан скрипт.
#!/бин/баш
cd ..
docker-compose exec <container_name> pipenv run python manage.py dumpdata -o fixtures/dumpdata_test.json --indent 2
Запуск Pipenv важен, если вы используете pipenv, -o OUTPUT задает пункт назначения, --indent 2 изменяет встроенный формат в формат beauty json. Swif сказал о django-admin, мое решение все еще с manage.py
Это должен быть принятый ответ, хотя стоит отметить, что разница между django-admin и manage.py заключается только в том, что один из них должен вызываться внутри проекта, тогда как django-admin может вызываться из любого каталога, поскольку для этого требуется установить переменные env, чтобы он знал, где найти настройки проекта.
Да, но я могу принять свой ответ только через 2 дня
В качестве примечания, не связанного с вашим вопросом, обычно не требуется иметь как док-контейнер, так и внутри виртуальную среду. Они оба помещают установленные пакеты в песочницу для необходимых приложений. Исключение может быть, если у вас есть два или более приложений django, работающих на одном и том же экземпляре докера, но я не мог представить, почему одно из них будет делать это, а не иметь второй экземпляр докера.