尧图网页设计 
taipy run 的 --development 与 --experiment 运行模式怎么选【免费下载链接】taipyTurns Data and AI algorithms into production-ready web applications in no time.项目地址: https://gitcode.com/GitHub_Trending/ta/taipy开发 Taipy 应用时每次用taipy run启动都会遇到同一个选择这一次运行是「清掉旧的开发数据重新开始」还是「把当前应用状态存成一个可以回查的版本」。--development和--experiment这两个互斥参数就是控制这件事的。本文基于仓库中 CLI 参数的定义taipy/core/_cli/_core_cli.py、run命令的实现taipy/common/_cli/_run_cli.py以及核心测试tests/core/test_core_cli.py说明两种模式各自的行为以及如何选择和验证。两种模式在做什么两个参数在_CoreCLI中注册官方 help 文本对行为的描述是--development以 development 模式运行时在启动新的 Taipy 应用之前上一个 development 版本的所有实体都会被删除When execute Taipy application indevelopmentmode, all entities from the previous development version will be deleted before running new Taipy application。--experiment [VERSION]以 experiment 模式运行时当前 Taipy 应用会被保存到一个新版本。如果版本名已存在会先检查与当前 Python Config 的兼容性再运行应用如果不指定版本名版本号是一个随机字符串。两者的关键差异可以直接从测试断言中读出tests/core/test_core_cli.py版本号是否变化。development 模式每次运行复用同一个固定的开发版本号version_number等于 development version重复--development运行后版本数不变而每运行一次--experiment就产生一个新版本len(_VersionManager._get_all())随之加一见test_version_number_when_switching_mode。旧数据是否保留。development 模式再次启动时上一轮开发版本创建的 scenario、task、data node、job 等实体全部被删除只剩新版本的数据而 experiment 模式运行后旧版本的实体仍然可查见test_dev_mode_clean_all_entities_of_the_latest_version。缺省行为。不带任何模式参数时Config.core.mode默认为developmenttaipy/core/config/core_section.py 中_DEFAULT_MODE developmenttest_orchestrator_cli_no_arguments断言了这一点。也就是说taipy run app.py不加参数就等价于开发模式。运行命令怎么写前置条件按 INSTALLATION.md 安装 Taipy例如pip install taipy。安装后taipy命令来自 pyproject.toml 的[project.scripts]入口taipy taipy._entrypoint:_entrypoint。taipy run的完整用法来自_RunCLI的参数定义taipy run application_main_file [--development | --experiment VERSION] [--taipy-force | --taipy-no-force]application_main_file是必填的位置参数即你的应用主文件例如main.py。--development与--experiment属于互斥组一次只能选一个。--experiment后面可选跟一个版本名如1.0、2.1。--taipy-force/--taipy-no-force也互斥force 用于在版本配置有冲突时强制覆盖并运行默认 False--no-force则在任何 Config 冲突存在时停止应用。需要注意的机制taipy run本身不直接启动应用而是用子进程执行[sys.executable, 主文件, ...]并把模式参数加上--taipy-前缀如--taipy-development透传给应用进程见_run_cli.py中的add_taipy_prefix。另外参数中写external-args关键字之后的内容会被原样作为外部参数传给应用不会被加上--taipy-前缀taipy run main.py --experiment 1.0 external-args --my-own-flag什么时候选 development什么时候选 experiment日常迭代选 development缺省即可。开发期间每次改完配置、函数或数据都重启应用时development 模式会把上一轮开发版本的所有实体清掉再重建保证你看到的始终是最新一次运行的状态不会累积历史。测试test_dev_mode_clean_all_entities_of_the_latest_version展示了这一点先以 development 模式建场景并提交产生 1 个 scenario、2 个 data node、1 个 job切到 experiment 模式再建一版最后切回--development运行——断言显示第一版开发版本的数据全部消失实体数量回到只有新开发版本的那份。需要留存一份可回查的快照时选 experiment。例如验证某次配置改动前后的差异、或给一次实验性运行留个存档taipy run main.py --experiment不指定版本名时会得到一个随机版本号每运行一次就多一个版本。如果想让某个版本名在多次运行间保持稳定比如始终复现1.0这个版本就显式给出版本名taipy run main.py --experiment 1.0此时有一个重要的边界行为同名 experiment 版本再次运行且当前 Config 与该版本已保存的配置不一致时应用会直接退出抛出SystemExit并在日志中逐条列出配置差异。测试test_modified_config_properties_without_force中断言的日志片段包括DATA_NODE d3 was added JOB max_nb_of_workers was added DATA_NODE d0 was removed DATA_NODE d2 has attribute default_path modified SCENARIO my_scenario has attribute frequency modified TASK my_task has attribute function modified遇到这种退出时有两条路加--taipy-force强制用当前配置覆盖该版本并继续运行见test_force_override_experiment_version修改Config.configure_global_app后不带 force 再次--experiment 1.0会SystemExit加上--taipy-force则正常运行或者改用一个新的版本名让旧版本原样保留。一个例外对 job 执行配置的修改如JOB mode、JOB max_nb_of_workers只会在日志中记录「was modified / was added」不会阻止应用启动见test_modified_job_configuration_dont_block_application_run。如何验证版本与模式版本管理有独立的manage-versions子命令taipy/core/_version/_cli/_version_cli.py用来核对当前各版本的模式归属taipy manage-versions --list输出为表格列包括Version number、Mode、Creation date最新的版本会带(latest)标记。Mode 列显示Development或ExperimentEnterprise 版还会出现Production见 core_section.py 中mode参数说明可选值为development、experimentEnterprise 版另有production。测试test_list_versions断言了该表格的列结构与 Development/Experiment/latest 的标注逻辑。对比两个版本的配置差异taipy manage-versions --compare-config 1.0 2.0测试中期望的输出形如来自 tests/core/_version/test_version_cli.py 的断言内容属测试示例Differences between version 1.0 Configuration and version 2.0 Configuration: DATA_NODE d2 has attribute default_path modified: foo.csv - bar.csv不需要的版本可以删除taipy manage-versions --delete 1.0注意副作用--delete会删除该版本及其关联实体不可恢复成功后日志为Successfully delete version 1.0.。删除不存在的版本会报错Version xxx does not exist.。另外还有--rename OLD_VERSION NEW_VERSION用于重命名版本若新名字已被占用会报Version name xxx is already used.。不想用命令行参数时这两个 CLI 参数最终写入的是 CORE 配置节的mode与version_number键见_CoreCLI.handle_command。因此也可以在应用代码里用等价的方式固定行为Config.configure_core(modeexperiment, version_number1.0, forceFalse)configure_core的文档core_section.py明确了两点version_number在 development 模式下会被忽略force为 True 时即使配置有冲突也覆盖运行。命令行参数适合临时切换代码里写死则适合固定部署形态。选择小结改代码、改配置的日常开发用taipy run main.py缺省或显式--development接受「每次启动清空上一轮开发版本」的行为要留存一次运行对应的应用与实体快照--experiment需要版本名跨次复现时写成--experiment 1.0复用同名 experiment 版本但配置已变动确认差异后加--taipy-force或换一个新版本名跑完用taipy manage-versions --list核对版本模式与 latest 归属用--compare-config核对两次运行的配置差异。【免费下载链接】taipyTurns Data and AI algorithms into production-ready web applications in no time.项目地址: https://gitcode.com/GitHub_Trending/ta/taipy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 taipy run 的 --development 与 --experiment 运行模式怎么选？
taipy run 的 --development 与 --experiment 运行模式怎么选【免费下载链接】taipyTurns Data and AI algorithms into production-ready web applications in no time.项目地址: https://gitcode.com/GitHub_Trending/ta/taipy开发 Taipy 应用时每次用taipy run启动都会遇到同一个选择这一次运行是「清掉旧的开发数据重新开始」还是「把当前应用状态存成一个可以回查的版本」。--development和--experiment这两个互斥参数就是控制这件事的。本文基于仓库中 CLI 参数的定义taipy/core/_cli/_core_cli.py、run命令的实现taipy/common/_cli/_run_cli.py以及核心测试tests/core/test_core_cli.py说明两种模式各自的行为以及如何选择和验证。两种模式在做什么两个参数在_CoreCLI中注册官方 help 文本对行为的描述是--development以 development 模式运行时在启动新的 Taipy 应用之前上一个 development 版本的所有实体都会被删除When execute Taipy application indevelopmentmode, all entities from the previous development version will be deleted before running new Taipy application。--experiment [VERSION]以 experiment 模式运行时当前 Taipy 应用会被保存到一个新版本。如果版本名已存在会先检查与当前 Python Config 的兼容性再运行应用如果不指定版本名版本号是一个随机字符串。两者的关键差异可以直接从测试断言中读出tests/core/test_core_cli.py版本号是否变化。development 模式每次运行复用同一个固定的开发版本号version_number等于 development version重复--development运行后版本数不变而每运行一次--experiment就产生一个新版本len(_VersionManager._get_all())随之加一见test_version_number_when_switching_mode。旧数据是否保留。development 模式再次启动时上一轮开发版本创建的 scenario、task、data node、job 等实体全部被删除只剩新版本的数据而 experiment 模式运行后旧版本的实体仍然可查见test_dev_mode_clean_all_entities_of_the_latest_version。缺省行为。不带任何模式参数时Config.core.mode默认为developmenttaipy/core/config/core_section.py 中_DEFAULT_MODE developmenttest_orchestrator_cli_no_arguments断言了这一点。也就是说taipy run app.py不加参数就等价于开发模式。运行命令怎么写前置条件按 INSTALLATION.md 安装 Taipy例如pip install taipy。安装后taipy命令来自 pyproject.toml 的[project.scripts]入口taipy taipy._entrypoint:_entrypoint。taipy run的完整用法来自_RunCLI的参数定义taipy run application_main_file [--development | --experiment VERSION] [--taipy-force | --taipy-no-force]application_main_file是必填的位置参数即你的应用主文件例如main.py。--development与--experiment属于互斥组一次只能选一个。--experiment后面可选跟一个版本名如1.0、2.1。--taipy-force/--taipy-no-force也互斥force 用于在版本配置有冲突时强制覆盖并运行默认 False--no-force则在任何 Config 冲突存在时停止应用。需要注意的机制taipy run本身不直接启动应用而是用子进程执行[sys.executable, 主文件, ...]并把模式参数加上--taipy-前缀如--taipy-development透传给应用进程见_run_cli.py中的add_taipy_prefix。另外参数中写external-args关键字之后的内容会被原样作为外部参数传给应用不会被加上--taipy-前缀taipy run main.py --experiment 1.0 external-args --my-own-flag什么时候选 development什么时候选 experiment日常迭代选 development缺省即可。开发期间每次改完配置、函数或数据都重启应用时development 模式会把上一轮开发版本的所有实体清掉再重建保证你看到的始终是最新一次运行的状态不会累积历史。测试test_dev_mode_clean_all_entities_of_the_latest_version展示了这一点先以 development 模式建场景并提交产生 1 个 scenario、2 个 data node、1 个 job切到 experiment 模式再建一版最后切回--development运行——断言显示第一版开发版本的数据全部消失实体数量回到只有新开发版本的那份。需要留存一份可回查的快照时选 experiment。例如验证某次配置改动前后的差异、或给一次实验性运行留个存档taipy run main.py --experiment不指定版本名时会得到一个随机版本号每运行一次就多一个版本。如果想让某个版本名在多次运行间保持稳定比如始终复现1.0这个版本就显式给出版本名taipy run main.py --experiment 1.0此时有一个重要的边界行为同名 experiment 版本再次运行且当前 Config 与该版本已保存的配置不一致时应用会直接退出抛出SystemExit并在日志中逐条列出配置差异。测试test_modified_config_properties_without_force中断言的日志片段包括DATA_NODE d3 was added JOB max_nb_of_workers was added DATA_NODE d0 was removed DATA_NODE d2 has attribute default_path modified SCENARIO my_scenario has attribute frequency modified TASK my_task has attribute function modified遇到这种退出时有两条路加--taipy-force强制用当前配置覆盖该版本并继续运行见test_force_override_experiment_version修改Config.configure_global_app后不带 force 再次--experiment 1.0会SystemExit加上--taipy-force则正常运行或者改用一个新的版本名让旧版本原样保留。一个例外对 job 执行配置的修改如JOB mode、JOB max_nb_of_workers只会在日志中记录「was modified / was added」不会阻止应用启动见test_modified_job_configuration_dont_block_application_run。如何验证版本与模式版本管理有独立的manage-versions子命令taipy/core/_version/_cli/_version_cli.py用来核对当前各版本的模式归属taipy manage-versions --list输出为表格列包括Version number、Mode、Creation date最新的版本会带(latest)标记。Mode 列显示Development或ExperimentEnterprise 版还会出现Production见 core_section.py 中mode参数说明可选值为development、experimentEnterprise 版另有production。测试test_list_versions断言了该表格的列结构与 Development/Experiment/latest 的标注逻辑。对比两个版本的配置差异taipy manage-versions --compare-config 1.0 2.0测试中期望的输出形如来自 tests/core/_version/test_version_cli.py 的断言内容属测试示例Differences between version 1.0 Configuration and version 2.0 Configuration: DATA_NODE d2 has attribute default_path modified: foo.csv - bar.csv不需要的版本可以删除taipy manage-versions --delete 1.0注意副作用--delete会删除该版本及其关联实体不可恢复成功后日志为Successfully delete version 1.0.。删除不存在的版本会报错Version xxx does not exist.。另外还有--rename OLD_VERSION NEW_VERSION用于重命名版本若新名字已被占用会报Version name xxx is already used.。不想用命令行参数时这两个 CLI 参数最终写入的是 CORE 配置节的mode与version_number键见_CoreCLI.handle_command。因此也可以在应用代码里用等价的方式固定行为Config.configure_core(modeexperiment, version_number1.0, forceFalse)configure_core的文档core_section.py明确了两点version_number在 development 模式下会被忽略force为 True 时即使配置有冲突也覆盖运行。命令行参数适合临时切换代码里写死则适合固定部署形态。选择小结改代码、改配置的日常开发用taipy run main.py缺省或显式--development接受「每次启动清空上一轮开发版本」的行为要留存一次运行对应的应用与实体快照--experiment需要版本名跨次复现时写成--experiment 1.0复用同名 experiment 版本但配置已变动确认差异后加--taipy-force或换一个新版本名跑完用taipy manage-versions --list核对版本模式与 latest 归属用--compare-config核对两次运行的配置差异。【免费下载链接】taipyTurns Data and AI algorithms into production-ready web applications in no time.项目地址: https://gitcode.com/GitHub_Trending/ta/taipy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考