Пай легко читать, Json понятнее всем. Я храню в пай

Я вот думаю как импортить config.json в нескольких модулях

На StackOverflow такой вопрос был на днях, сошлись на Json

Можешь скинуть линк?

Он в бездне, я уже не найду (

Не отмечался там поэтому нет в истории

Fuck. Не могу определиться че использовать для конфига. config.py or config.json. Нужен импорт конфига в нескольких модулях.

ИМХО json, если конфиг не сильно длинный

Ой, все

Я затупил

Немного не так прочитал, перепутал

Крч зря наехал, прошу прощения

А чтобы никого не смущать -- удалю свое сообщение, ладно?

А оно все равно на сервере живёт

Fuck. Не могу определиться че использовать для конфига. config.py or config.json. Нужен импорт конфига в нескольких модулях.

Первое - антипаттерн

Первое - антипаттерн

Понимаю. Но как мне импортировать config.json в несколько модулей.

Google it

Если нашел в гугле, тут бы не српашивал:)

Ищи лучше

Ищи на английском

json.load чтоли потеряли?

В каждом модуле подгружать config.json в переменную, это первое что пришло в голову. Пока что ищу более изящное решение.

заимпортить в один модуль, который уже простым импортом пихать в остальные

import config, а внутри config.py уже ковырять json

я так не уверен, что это выполняется автоматически на все

просто если нужно грузить его ВО ВСЕ модули

то мб это проблема архитектуры, я не знаю

Ну раз они делят область видимости

точнее

import config, а внутри config.py уже ковырять json

т.е. будет что то вида: # config.py cfg = open('config.json', 'r').read() # etc.py import config name = config.cfg['name'] Опять же так себе.

покажи, как ты хочешь в etc.py?

т.е. будет что то вида: # config.py cfg = open('config.json', 'r').read() # etc.py import config name = config.cfg['name'] Опять же так себе.

вот у меня тоже такое, но тоже пугает

покажи, как ты хочешь в etc.py?

import config name = config['name']

s/тоже/тож/;s/тоже//;s/тож/тоже/;

import config name = config['name']

#etc: from config import g_conf g_conf('name')

то мб это проблема архитектуры, я не знаю

Очень может быть. У меня две части системы, которые по сути одно приложение: 1. Некий модуль который выполняет некие функции, которому нужны из конфига например токены от внешнего API. 2. Это API который предоставляет HTTP интерфейс для использования модуля, ему тоже нужны свои конфиги.

#etc: from config import g_conf g_conf('name')

Кстати да:)

Очень может быть. У меня две части системы, которые по сути одно приложение: 1. Некий модуль который выполняет некие функции, которому нужны из конфига например токены от внешнего API. 2. Это API который предоставляет HTTP интерфейс для использования модуля, ему тоже нужны свои конфиги.

вот точь-в-точь моя ситуация

#config def g_conf(key): if _conf is None: read_conf() return _conf.get(key)

как-то так

как-то так

Да, но опять же. config.py + config.json два файла, по факту для одного и того же, так себе затея.

Да, но опять же. config.py + config.json два файла, по факту для одного и того же, так себе затея.

кидаешь его глубоко в libs и всё

Возможно есть еще предложения? И зайдем в корень: стоит ли вообще так централизовать конфиг? или проще для каждой части свой.

и в черный ящик

Да, но опять же. config.py + config.json два файла, по факту для одного и того же, так себе затея.

ну так просто config.py вы тут забраковали, антипатерном обозвали.

Возможно есть еще предложения? И зайдем в корень: стоит ли вообще так централизовать конфиг? или проще для каждой части свой.

если какие-то части конфига повторяется, то определенно стоит

"простое лучше сложного", помните?

"простое лучше сложного", помните?

опять дзена перечитал

ну так просто config.py вы тут забраковали, антипатерном обозвали.

Ну по сути так и есть. Конфиги должны хранится в .ini, .json, .yml, .etc, но никак не в .py

:)

Ну по сути так и есть. Конфиги должны хранится в .ini, .json, .yml, .etc, но никак не в .py

неистово плюсую

только вот .etc уберу

только вот .etc уберу

.etc - и т.д.

почти неделю не писал Уже как легаси код какой-то

Ну по сути так и есть. Конфиги должны хранится в .ini, .json, .yml, .etc, но никак не в .py

тогда я не понимаю, почему не нравится два файла.

Чем плох config.py с классами типа Development, Production и наследованием повторяющихся частей?

Чем плох config.py с классами типа Development, Production и наследованием повторяющихся частей?

религия инишников на канале.

Чем плох config.py с классами типа Development, Production и наследованием повторяющихся частей?

потому что от такого файла я ожидаю предварительную настройку, и ничего больше

Никто не мешает не писать туда чего-то большее

исполняемый файл для хранения конфигов это почти как хардкод по мне

Никто не мешает не писать туда чего-то большее

Я мешаю)

Попробую поковырять англогугл. Если чето найду - отпишу.

О, чати. А есть что-то наподобие nodemon для питона? (при изменении одного из файлов перезапуск процесса)

Попробую поковырять англогугл. Если чето найду - отпишу.

Бужу ждать)

Самое интересное что, flask, django, fabric плюют на такие вещи и тупо фигачат в .py

ERROR: S client not available

В проекте используется БД?

потому что это: 1. просто 2. работает 3. расширяемо

В проекте используется БД?

Нет. Как это связано с обсуждаемым вопросом?:)

потому что это: 1. просто 2. работает 3. расширяемо

ещё и авто-комплит есть.

Нет. Как это связано с обсуждаемым вопросом?:)

Приложение какого типа? Демон? Гуи? Если демон, то через что запускается? Какая ос?

Приложение какого типа? Демон? Гуи? Если демон, то через что запускается? Какая ос?

linux, приложение - сервис. Запускаем API и сервер для статики. В статике JS код, который делает запросы к API.

Если запускается api через что-то наподобии nginx/gunicorn, то я бы сделал ini, его возможностей должно хватать, если захочется, то переписать на что-то еще не составит проблем, если правильно абстрагироваться от реализации конфига

правильно абстрагироваться от реализации конфига и не забудьте про конструктор фабрики конфигов!

Если запускается api через что-то наподобии nginx/gunicorn, то я бы сделал ini, его возможностей должно хватать, если захочется, то переписать на что-то еще не составит проблем, если правильно абстрагироваться от реализации конфига

У меня конфиг один для API и непосредственно модуля реализующего функционал, к которому обращается API

Это меньшее из зол. При таком подходе нет выполняемого кода в конфиге и остается авто-комплит/references в приложении, что избавляет от опечаток при вызовах.

Спасибо за предложение.

я вот тут чай пил и всё время вопрос думал: а как связан формат конфигов и способ запуска приложения?

если через upstart/systemd, то конфиг кладется в /etc/default и потом значения из него передаются в аргументах запускаемому приложению

если докер-контейнер, то лучше всего использовать переменные окружения, если конфигурация большая, то создавать файл с переменными окружения и указывать его при запуске контейнера

Бужу ждать)

Итак, бегло изучил тему. 1. .py не формат файлов конфигурации 2. Использование .json, .ini, .yml дает возможность динамически изменять конфигурацию приложения, без его полного перезапуска 3. Конфигурация должна быть декларативной 4. Разрабы пишут о проблемах при использовании конфига в формате .py. Какие именно проблемы не нашел. 5. Не рекомендуется использовать .json, .yml, т.к. они допускают вложенность, которая создает бардак. Итог: используем configparser и не выё:)

Итак, бегло изучил тему. 1. .py не формат файлов конфигурации 2. Использование .json, .ini, .yml дает возможность динамически изменять конфигурацию приложения, без его полного перезапуска 3. Конфигурация должна быть декларативной 4. Разрабы пишут о проблемах при использовании конфига в формате .py. Какие именно проблемы не нашел. 5. Не рекомендуется использовать .json, .yml, т.к. они допускают вложенность, которая создает бардак. Итог: используем configparser и не выё:)

kjk

Спасибо)

.properties решают

Это конечно из джава мира

АХХАХАХАХ

https://github.com/parrotgeek1/amnok/blob/master/README.md#south-korea-is-best-korea

просто 11/10

https://github.com/parrotgeek1/amnok/blob/master/README.md#south-korea-is-best-korea

лол

ЛОЛhttps://twitter.com/beist/status/700057217702047745

Еще нашел аргумент против config.py - есть шанс что из декларативного описания, он превратится в императивный код.

:LOL:

You may contribute actual files by adding it to the "resources" folder. Please note that these files are mostly user-contributed and may be malicious, so do your own homework before running them. If you see something bad we haven't noticed, please open an issue

так, 100 символов. как файл хранится символами? что за хрень?

Длина задаётся под название файла, сам файл хранится в на диске или любом другом хранилище. Документацию по диагонали читаешь?

Длина задаётся под название файла, сам файл хранится в на диске или любом другом хранилище. Документацию по диагонали читаешь?

видимо. не нашел этой тонкости в доке.

видимо. не нашел этой тонкости в доке.

Ну, сам посуди хранить файлы в БД в поле с типом varchar это нормально?