groupbwt
Ideas
- вынести бизнес-логику парсинга и извлечения данных, а также pipelines в классы-сервисы
есть идея в корне оставить всякие штуки. которые относятся к редактору/гиту/лицензиям, а все, что относится к poetry запихнуть в src т.к. сейчас .venv ставит на один уровень с src/sql. Но например для sql этот .venv вообще не нужен
@tyorn - в принципе, обсудили. Текущая структура решает проблемы с импортами, хаками sys.path и в целом ближе к тому, что является общепринятым в проектах на Python. Есть намерение перекроить структуру проекта под многоязычность, тогда уже будет актуально переносить pyproject и т.д.
2020-06-09. Идеи от @tyorn:
1."унифицированный экспорт. я сам его начал пилить еще месяца 4 назад. аж целых 4 часа потратил. и как бы все, на том он и закончился. на чистом csv и openpyxl запилить абстрактный экспорт из плоских таблиц в два формата 2. конвертация темплаты в гибридную из жс + скрапи. 3. какую-то темплату или обходной путь через аргументы команды или обертку. короче давно хочу не пилить sh скрипты под pm2. это можно костылями, но надо либо подтвердить шо костыль не костыль либо найти няшный способ
@KristobalJunta
какую-то темплату или обходной путь через аргументы команды или обертку. короче давно хочу не пилить sh скрипты под pm2. это можно костылями, но надо либо подтвердить шо костыль не костыль либо найти няшный способ
В одном из проектов scrapy запускается так (pm2.example.js):
module.exports = { "apps": [ { "name": "comprehend_fill_lang_field_using_lingua_...", "script": "/bin/bash", "instances": 1, "max_memory_restart": "1G", "exp_backoff_restart_delay": 600000, "error_file": "./logs/...", "out_file": "./logs/...", "merge_logs": true, "args": [ "-c", "pipenv run scrapy fill_lang_field_using_lingua_for_comprehend_processing_table --max_processed_record=0" ] }, ] }
Или у этого способа есть ограничения?
@AntonGsv этот способ как раз тот самый "костыль под сомнением" :) Оно лучше, чем писать специально скрипт, но тоже не совсем идеально. На сейчас сам таким пользуюсь.