数据处理模块是否需合并
https://github.com/ticoAg/HowToCook/tree/data_extract
写了一点读取和处理数据的 可为打tag以及食材检索提供支持,目前由于数据格式问题,分出来的食材不是很干净,但应该够用
main:view:69 - 200-300字: 3篇, 油酥,蒜香酱油,话梅煮毛豆 main:view:71 - 300-400字: 13篇 main:view:71 - 400-500字: 45篇 main:view:71 - 500-600字: 44篇 main:view:71 - 600-700字: 49篇 main:view:71 - 700-800字: 52篇 main:view:71 - 800-900字: 28篇 main:view:71 - 900-1000字: 20篇 main:view:71 - 1000-1100字: 13篇 main:view:71 - 1100-1200字: 10篇 main:view:69 - 1200-1300字: 5篇, 乡村啤酒鸭,水煮鱼,西红柿土豆炖牛肉,无骨鸡爪,尖叫牛蛙 main:view:69 - 1300-1400字: 5篇, 手工水饺,红烧鱼头,豆角焖面,西红柿鸡蛋挂面,回锅肉 main:view:69 - 1400-1500字: 5篇, 牛油火锅底料,日式肥牛丼饭,魔芋蛋糕,卤菜,葱油桂鱼 main:view:69 - 1500-1600字: 1篇, 腊八粥 main:view:69 - 1600-1700字: 1篇, 水煮肉片 main:view:69 - 1700-1800字: 3篇, 老式锅包肉,台式卤肉饭,柱候牛腩 main:view:69 - 1800-1900字: 1篇, 宫保鸡丁 main:view:69 - 2000-2100字: 1篇, 示例菜 main:view:69 - 2700-2800字: 1篇, 牛排 main:view:69 - 2900-3000字: 1篇, 戚风蛋糕 main:view:69 - 4700-4800字: 1篇, 基础牛奶面包 main:view:73 - 共计菜谱: 302, 食材: 1273
是否需要提pr合并进来
感谢大佬的贡献!看起来你解析了所有markdown并得到了它们需要的材料。暂时不计划合并,考虑到突然莫名其妙多个python文件在仓库里有点儿令其它的贡献人困惑,除非这个模块是我们编译必需的。我建议试试让这个模块进一步做一些实用的用例,例如我们可以加入到CI里,自动化检查是否步骤中出现了未提及的原材料等。或者你还能想到什么用例都可以整整活。现在社区里比较需要的其实是:输入我冰箱里的材料,输出我可以做哪些菜。就是这种功能我不知道好不好加到mkdocs里,还是需要单独出个container。
另外对于标签的issue #3 ,我个人建议引入一些ai的因素,但在开始之前我们需要非常严格的定义一份标准,就是哪些要素需要进入tag。例如原材料肯定不太需要tag,除非它太离谱。那么多离谱就需要严格的定义一下。
因为tag毕竟还是方便搜索和索引。
感谢大佬的贡献!看起来你解析了所有markdown并得到了它们需要的材料。暂时不计划合并,考虑到突然莫名其妙多个python文件在仓库里有点儿令其它的贡献人困惑,除非这个模块是我们编译必需的。我建议试试让这个模块进一步做一些实用的用例,例如我们可以加入到CI里,自动化检查是否步骤中出现了未提及的原材料等。或者你还能想到什么用例都可以整整活。现在社区里比较需要的其实是:输入我冰箱里的材料,输出我可以做哪些菜。就是这种功能我不知道好不好加到mkdocs里,还是需要单独出个container。
如果是基于本仓库的食谱实现输入材料,输出可以做哪些菜的话,需要这部分处理出来的数据(如果不依赖第三方且最小资源消耗),基于p1针对输入的关键词(完全匹配材料+模糊匹配),检索材料数量重合度最高的食谱(这样≈把数据处理的逻辑集成到项目构建中了)
另外这个环节可以引入tag, 对于匹配出的食谱进行二次筛选
另外对于标签的issue #3 ,我个人建议引入一些ai的因素,但在开始之前我们需要非常严格的定义一份标准,就是哪些要素需要进入tag。例如原材料肯定不太需要tag,除非它太离谱。那么多离谱就需要严格的定义一下。
因为tag毕竟还是方便搜索和索引。
实现都好实现,一半天就写完了,就是确定都要什么,感觉issue收集意见及探讨时延好高哈哈哈哈哈
食材检索简单做了,可以测试下效果 https://github.com/ticoAg/HowToCook/tree/data_extract/tasks