Структура проекта Flask для рабочего процесса на основе grunt - PullRequest
Новая
       37

Структура проекта Flask для рабочего процесса на основе grunt

0 голосов
/ 03 мая 2018

Недавно я приобрел шаблон администратора HTML / CSS / Js на основе фреймворка Bootstrap. Он в основном покрывал все мои потребности в MVP, и я планировал немного его настроить, а затем подключить уже разработанную внутреннюю часть через колбу.

Я совершенно неопытен в этой области, поэтому меня впечатлил автоматический рабочий процесс, который использовался этим шаблоном администратора. Базовая структура следующая: 

root/
├── dist/
│   └── html/
│       ├── assets/
│       └── all_pages.html
├── grunt/
│   └── tasks/
├── node_modules/
├── src/
│   ├── assets/
│   ├── html/
│   ├── js/
│   └── sass/
├── Gruntfile.js
└── package.json

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

Sass скомпилированы в стиле css для производства, и весь код минимизируется и копируется в папку dist в зависимости от настроек.

Вы можете легко разработать путь src и использовать задачу grunt «сервер», чтобы отслеживать изменения и напрямую отображать их перед отправкой всего в рабочую папку «dist».

Мои проблемы возникают, когда я пытаюсь сохранить это поведение с помощью приложения фляги, взаимодействующего с ним.

Мое приложение для колб использует следующую структуру: 

root/
├── __init__.py
├── templates/
│   ├── layout.html
│   └── bp1/
│   │   ├── layout.html
│   │   └── other_pages.html
│   └── bp2/
│       ├── layout.html
│       └── other_pages.html
├── views/
│   ├── __init__.py
│   ├── bp1.py.py
│   └── bp2.py.py
├── static/
│   ├── css/
│   ├── js/
│   └── img/
├── Dockerfile
└── requirements.txt

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

Мой вопрос здесь такой: как, черт возьми, я должен подойти к слиянию этих двух парней? Как создать проект колбы с разделением src-dist и рабочим процессом, аналогичным описанному выше?

Я хотел бы сохранить все полезные функции (я смог заметить своими навыками) шаблона администратора и иметь что-то с:

  • Разделение папок src и dist ... так что все элементы sass, неиспользуемый / удаленный код js и html-страницы находятся только в папке "src" разработки и не будут использоваться в рабочей среде
  • автоматизация grunt для компиляции sass, очистки каталогов lib, наблюдения за изменениями, npmcopy (для установки пакетов с помощью npm и перемещения только необходимых файлов в производство), уведомлений, минимизации и т. Д. *
  • Развертывание на основе образа Docker, которое основано только на ресурсе dist-Generated и игнорирует материал "src-development".

1 Ответ

0 голосов
/ 07 мая 2018

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

Структура 

root/
├── src/
│   ├── __init__.py
│   ├── models.py
│   ├── database.py
│   ├── static/
│   │   ├── css/
│   │   │   └── app.css
│   │   ├── js/
│   │   ├── img
│   │   └── lib
│   ├── templates/
│   │   ├── layout.html
│   │   ├── bp1/
│   │   │   ├── layout.html
│   │   │   └── other_pages.html
│   │   └── bp2/
│   │       ├── layout.html
│   │       └── other_pages.html
│   ├── views/
│   │   ├── __init__.py
│   │   ├── bp1.py
│   │   └── bp2.py
│   └── sass/
├── dist/
│   ├── __init__.py
│   ├── models.py
│   ├── database.py
│   ├── static/
│   │   ├── css/
│   │   │   └── app.css
│   │   ├── js/
│   │   ├── img
│   │   └── lib
│   ├── templates/
│   │   ├── layout.html
│   │   ├── bp1/
│   │   │   ├── layout.html
│   │   │   └── other_pages.html
│   │   └── bp2/
│   │       ├── layout.html
│   │       └── other_pages.html
│   └── views/
│       ├── __init__.py
│       ├── bp1.py
│       └── bp2.py
├── templates/
│   ├── layout.html
│   └── bp1/
│   │   ├── layout.html
│   │   └── other_pages.html
│   └── bp2/
│       ├── layout.html
│       └── other_pages.html
├── views/
│   ├── __init__.py
│   ├── bp1.py.py
│   └── bp2.py.py
├── static/
│   ├── css/
│   ├── js/
│   └── img/
├── instance/
│   └── flask.cfg
├── grunt/
│   └── tasks/
├── static/
├── node_modules/
├── venv/
├── Gruntfile.js
├── package.json
├── Dockerfile
├── .gitignore
└── requirements.txt

Workflow

  • пакеты устанавливаются с npm и package.json (генерируется node_modules).
  • python virtualenv конфигурируется с использованием 'needs.txt' и связывается с 'venv'.
  • вызывается grunt задачи и использует npmcopy для перемещения только необходимых файлов в src/static/lib, который используется шаблонами фляг как: static/lib для обеспечения совместимости с src-dist.
  • Задача grunt способна скомпилировать sass-части и создать app.css в static/css.
  • Несколько других заданий выполняют другие полезные вещи, такие как минификация.
  • Задача Grunt по умолчанию одновременно выполняет «задачу наблюдения» и запускает flask run, чтобы обеспечить плавное продолжение разработки (подробнее об этом позже).
  • grunt dist создает в папке dist готовый для производства проект колбы со всеми пакетами, стилями и страницами, разработанными на предыдущих этапах.

Задача колбы Гранта

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

// Launch flask's server
grunt.registerTask('flask', 'Run flask server.', function() {
  var spawn = require('child_process').spawn;
  grunt.log.writeln('Starting Flask.');
  var PIPE = {
    stdio: 'inherit',
    env: {
      FLASK_APP: './src/__init__.py:create_app()',
      FLASK_ENV: 'development',
      LC_ALL: 'C.UTF-8',
      LANG: 'C.UTF-8'
    }
  };
  // more on venv later
  spawn('venv/bin/flask', ['run'], PIPE);
});

Настройка колбы для разработки

Для правильной работы команды flask run в режиме разработки настраиваются следующие параметры:

  • venv : символическая ссылка на python virtualenv, используемый для проекта.
  • instance / flask.cfg : папка экземпляра фляги

Gitignore

За исключением всей папки 'dist', они исключены из VCS:

  • venv;
  • папка экземпляра;
  • папка lib внутри src;
  • node_modules;

Заключение

Эта установка довольно удобна и ее легко поделиться. Локальные, легкие конфигурации позволяют всем работать аккуратно для разработки. Рабочий код может быть сгенерирован и затем быстро развернут / сконфигурирован в зависимости от стратегий (k8s, развертывание сервера, ...).

...