Https://Pastebin.Com/SG6JugK0 Что не так?

не видит файла .env. он точно в одной папке с main.py?

нет, на уровень ниже

поднял выше, так же падает ошибка спасибо, ошибка была в том, что одно обязательное поле не указал)

app/auth/config.py хотя может он в auth и должен лежать, надо проверить, с импортами и подобным всё путаюсь..

Стикер

А при чем тут папка с мейном?

а при чем тут глобалы?

Там ниже в коде

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

Нет, с чего бы

ни то ни то?

https://t.me/advice17/37

должен быть в "рабочей директории"?

Скорее всего. Или выше

.env в корне должен быть

В корне? Мммммм

но разве то откуда запускаем uvicorn ... это не рабочая директория? (статьи надо перечитать правда)

Условно проект: 1. Project-main 1.1 app - здесь само приложение 1.2 Dockerfile 1.3 .env итд

Я вообще не очень понял что у него где лежит

Все сложнее. Лучше всего вообще не юзать то .энв который юзает топикстартер

Думаешь правильно писать какую-то логику в конфиг файле?, который должен только инициализировать типы и дальше передавать их уже в другие функции, модули

трудно сказать.. чтобы в env не писать "магические" числа типа 3600?

в .env в каком формате записываешь данные, так? DB_HOST=localhost DB_PORT=5432 DB_USER=postgres DB_PASS=postgres

да

У тебя файл с инициализатором переменных называется config.py?

Это дефолты, норм

да, но это же ни на что не влияет

Поменяй здесь: config = AuthConfig() на settings = AuthConfig()

ну это же не файл уже

Какая IDE у тебя?

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

vsc

Попробуй, скажешь, что в итоге будет

да 100% не влияет, дурацкий эксперимент. тем более у меня вообще вот так @lru_cache() def get_settings(): return Settings()

О боже. Чую tiangolo насрал

плохая практика? уже не помню если честно для чего так написал. вроде эффект ведь тот же что записать в переменную.. а какие минусы?

1. Странное. Вызывает вопросы 2. Замаскированный глобал, те же проблемы что у него

Попробуй из корня запустить проект uvicorn app.main:app

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

Где константы?

да всё работает, ты где-то забыл переименовать думаю

ну эти сеттинги во время работы приложения ведь не меняются

Не меняются. Но это не константы. Они не известны заранее, а определяются где-то в процессе работы, но один раз.

Выше 4 поста. Прочитай

во время запуска. ок прочитаю тогда чтобы предметнее спрашивать, на 1 взгляд правда не вижу чему это может повредить

Ну вот в тестах, например, ты можешь захотеть подменить

точно не то что записано в энвах

Именно. Смотри, уже не константа :)

нет, я наоборот говорю точно не захочу подменить там то что записано в энвах, двусмысленно написал

Точно захочешь. Я тебе отвечаю. Ты стопудово захочешь протестить как ведёт себя приложение с разными вариантами настроек

Для этого делаешь несколько режимов: ["DEV", "TEST", "PROD"] Пример: class Settings(BaseSettings): MODE: Literal["DEV", "TEST", "PROD"] LOG_LEVEL: str DB_HOST: str DB_PORT: int DB_USER: str DB_PASS: str DB_NAME: str @property def DATABASE_URL(self): return f"postgresql+asyncpg://{self.DB_USER}:{self.DB_PASS}@{self.DB_HOST}:{self.DB_PORT}/{self.DB_NAME}" TEST_DB_HOST: str TEST_DB_PORT: int TEST_DB_USER: str TEST_DB_PASS: str TEST_DB_NAME: str @property def TEST_DATABASE_URL(self): return f"postgresql+asyncpg://{self.TEST_DB_USER}:{self.TEST_DB_PASS}@{self.TEST_DB_HOST}:{self.TEST_DB_PORT}/{self.TEST_DB_NAME}" FRONTEND_URL: str SMTP_HOST: str SMTP_PORT: int SMTP_USER: str SMTP_PASS: str REDIS_HOST: str REDIS_PORT: int SENTRY_DSN: str SECRET_KEY: str ALGORITHM: str class Config: env_file = ".env" settings = Settings() в .env соответсвенно тоже все прописываешь: MODE=DEV LOG_LEVEL=INFO DB_HOST=localhost DB_PORT=5432 DB_USER=postgres DB_PASS=postgres DB_NAME=crm_db TEST_DB_HOST=localhost TEST_DB_PORT=5432 TEST_DB_USER=postgres TEST_DB_PASS=postgres TEST_DB_NAME=test_first_crm

О, вы джангист?

Пиздец.

И что делать с этим TEST_DA6ABASE_URL, если код везде обращается к database_url?

в файле подключения БД: if settings.MODE == "TEST": DATABASE_URL = settings.TEST_DATABASE_URL DATABASE_PARAMETERS = {"poolclass": NullPool} else: DATABASE_URL = settings.DATABASE_URL DATABASE_PARAMETERS = {} engine = create_async_engine(DATABASE_URL, **DATABASE_PARAMETERS) async_session_maker = sessionmaker(engine, class_=AsyncSession, expire_on_commit=False)

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

а смпт не тестируете? надо добавить TEST_SMPT_HOST, TEST_SMPT_PORT, TEST_SMPT_USER и TEST_SMPT_PASS еще аналогично с редисом

Мммм. А если у меня тестов 1000 штук, мне делать 1000 доп параметров конфига и все в одном файле?

А ещё надо разные комбинации проверить

вооооо

Это пример, при желании можно все тестами покрыть

Суть в том, на какой БД ты это будешь тестировать, юнит и интеграционные

Представь, что у тебя в конфиге 10 булевых параметров. Ты хочешь протестить все комбинации. Как делать будешь?

Ни на какой. Для юниттестов мне НЕ нужна БД.

в чем именно? вроде много где слышал про dev/prod режимы..

httpx, да

Это сколько угодно. Но вот в дев режиме тебе нахуй не нужен адрес продововй базы и наоборот

тк на проде у тебя просто продовский бд урл, а дев собсна девелоперский бд урл и все

точно, два разных файла

без файлов, просто переменные окружения

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