基于 Grunt 工作流的 Flask 项目结构
Flask project structure for grunt based workflow
我最近购买了一个基于 Bootstrap 框架的 HTML/CSS/Js 管理模板。它基本上涵盖了我对 MVP 的所有需求，我的计划是对其进行一些定制，然后通过 flask 插入我已经开发的后端。
我在这方面经验不足，所以我对这个管理模板使用的自动工作流程印象深刻。
基本结构如下：
root/
├── dist/
│ └── html/
│ ├── assets/
│ └── all_pages.html
├── grunt/
│ └── tasks/
├── node_modules/
├── src/
│ ├── assets/
│ ├── html/
│ ├── js/
│ └── sass/
├── Gruntfile.js
└── package.json
感谢 grunt 任务和 npm 管理，处理资产非常容易，在 npm install 之后你可以用 grunt 处理所有事情。
sass 以 css 风格编译用于生产，所有代码都根据设置缩小并复制到 dist 文件夹。
您可以轻松地在 src 路径上进行开发，并使用 grunt 任务 "server" 来观察变化并直接显示它们，然后再将所有内容发送到生产文件夹 "dist"。
当我试图通过与之交互的烧瓶应用程序保持这种行为时，我的问题就出现了。
我的 flask 应用程序使用这个结构：
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
基本上，开发版和生产版之间没有区别，网络应用程序通过其 docker 图像部署。
我的问题是，到底应该如何处理这两个家伙的合并？如何拥有一个带有 src-dist 分离和类似于我上面描述的工作流程的烧瓶项目？
我想保留管理模板的所有优秀功能（我设法用我的技能注意到）并具有以下功能：
- src 和 dist 文件夹分离...以便所有 sass 项目、unused/discarded js 代码和 html 页面仅在开发 "src" 文件夹中并将不用于生产
- 用于编译的 grunt 自动化 sass、清理 lib 目录、监视更改、npmcopy（使用 npm 安装包并仅将需要的文件移动到生产环境）、通知、缩小等...
- Docker 基于映像的部署仅基于 "dist-generated" 资源并忽略 "src-development" 内容。
好吧，我想出了一个工作非常巧妙的设置，我认为值得分享给其他遇到类似情况时遇到困难或有疑问的人。
结构
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
工作流程
- 软件包与 npm 一起安装，package.json（生成 node_modules）。
- a python virtualenv 是使用 'requirements.txt' 和 linked 到 'venv' 配置的。
- 调用 grunt 任务并使用 npmcopy 仅将所需文件移动到
src/static/lib，烧瓶模板将其用作：static/lib 以保持 src-dist 兼容性。
- 一个 grunt 任务能够编译 sass 部分并在
static/css. 中创建 'app.css'
- 其他几个 grunt 任务做其他有用的事情，比如缩小。
- grunt 的默认任务同时执行 'watch task' 并启动
flask run 让开发顺利进行（稍后详细介绍）。
grunt dist 在 dist 文件夹中创建一个生产就绪的 flask 项目，其中包含在前面的步骤中开发的所有包、样式和页面。
Grunt 的烧瓶任务
这段简单的代码设法在本地启动一个 flask 服务器以开始开发。
// 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 设置
为了flask run命令在开发模式下正常运行，配置如下：
- venv: 符号 link 到用于项目的 python virtualenv。
- instance/flask.cfg: flask 实例文件夹
Gitignore
除了整个 'dist' 文件夹外，这些都被排除在 VCS 之外：
- venv;
- 实例文件夹；
- src里面的lib文件夹；
- node_modules;
结论
此设置非常方便，也很容易共享。本地、简单的配置让一切都可以为开发工作。
可以生成生产代码，然后根据策略（k8s、服务器部署等）快速 deployed/configured。
我最近购买了一个基于 Bootstrap 框架的 HTML/CSS/Js 管理模板。它基本上涵盖了我对 MVP 的所有需求，我的计划是对其进行一些定制，然后通过 flask 插入我已经开发的后端。
我在这方面经验不足，所以我对这个管理模板使用的自动工作流程印象深刻。 基本结构如下：
root/
├── dist/
│ └── html/
│ ├── assets/
│ └── all_pages.html
├── grunt/
│ └── tasks/
├── node_modules/
├── src/
│ ├── assets/
│ ├── html/
│ ├── js/
│ └── sass/
├── Gruntfile.js
└── package.json
感谢 grunt 任务和 npm 管理，处理资产非常容易，在 npm install 之后你可以用 grunt 处理所有事情。
sass 以 css 风格编译用于生产，所有代码都根据设置缩小并复制到 dist 文件夹。
您可以轻松地在 src 路径上进行开发，并使用 grunt 任务 "server" 来观察变化并直接显示它们，然后再将所有内容发送到生产文件夹 "dist"。
当我试图通过与之交互的烧瓶应用程序保持这种行为时，我的问题就出现了。
我的 flask 应用程序使用这个结构：
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
基本上，开发版和生产版之间没有区别，网络应用程序通过其 docker 图像部署。
我的问题是，到底应该如何处理这两个家伙的合并？如何拥有一个带有 src-dist 分离和类似于我上面描述的工作流程的烧瓶项目？
我想保留管理模板的所有优秀功能（我设法用我的技能注意到）并具有以下功能：
- src 和 dist 文件夹分离...以便所有 sass 项目、unused/discarded js 代码和 html 页面仅在开发 "src" 文件夹中并将不用于生产
- 用于编译的 grunt 自动化 sass、清理 lib 目录、监视更改、npmcopy（使用 npm 安装包并仅将需要的文件移动到生产环境）、通知、缩小等...
- Docker 基于映像的部署仅基于 "dist-generated" 资源并忽略 "src-development" 内容。
好吧，我想出了一个工作非常巧妙的设置，我认为值得分享给其他遇到类似情况时遇到困难或有疑问的人。
结构
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
工作流程
- 软件包与 npm 一起安装，package.json（生成 node_modules）。
- a python virtualenv 是使用 'requirements.txt' 和 linked 到 'venv' 配置的。
- 调用 grunt 任务并使用 npmcopy 仅将所需文件移动到
src/static/lib，烧瓶模板将其用作：static/lib以保持 src-dist 兼容性。 - 一个 grunt 任务能够编译 sass 部分并在
static/css. 中创建 'app.css'
- 其他几个 grunt 任务做其他有用的事情，比如缩小。
- grunt 的默认任务同时执行 'watch task' 并启动
flask run让开发顺利进行（稍后详细介绍）。 grunt dist在 dist 文件夹中创建一个生产就绪的 flask 项目，其中包含在前面的步骤中开发的所有包、样式和页面。
Grunt 的烧瓶任务
这段简单的代码设法在本地启动一个 flask 服务器以开始开发。
// 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 设置
为了flask run命令在开发模式下正常运行，配置如下：
- venv: 符号 link 到用于项目的 python virtualenv。
- instance/flask.cfg: flask 实例文件夹
Gitignore
除了整个 'dist' 文件夹外，这些都被排除在 VCS 之外：
- venv;
- 实例文件夹；
- src里面的lib文件夹；
- node_modules;
结论
此设置非常方便，也很容易共享。本地、简单的配置让一切都可以为开发工作。 可以生成生产代码，然后根据策略（k8s、服务器部署等）快速 deployed/configured。