Servo: 没有一个支持板条箱经过整洁检查或许可证检查

平台目录也有类似问题

查看被忽略文件的

一堆“我们的”代码（可能被定义为 https://github.com/servo/ 下的非分叉）在单独的存储库中并通过货物使用，因此对tidy.py不可见。 所以这没有完成，现在比我们切换到 Cargo 之前更难，一切都是一个子模块。

我们不能在每个 repo 中使用不同的配置进行整理吗？ 这些 repos 应该都在 CI 系统中，这样才能达到同样的目的。

每个存储库都有自己单独的 CI，可以有tidy.py副本，但这意味着当我们想要添加某些内容时需要更新许多副本。

将 tidy 移动到子模块？ 下载它并在 CI 期间运行它？ 有几种方法可以减少这个问题。

一个可以考虑的选项：将tidy作为servo_tidy上传到 PyPi，只要我们想整理就下载最新版本

编辑：杰克打败了我

@frewsxcv但我最喜欢科里更具体的建议版本。

好吧。 我已经考虑了一点，并认为我已准备好迎接挑战。 在实施任何事情之前，我会报告我的想法； 我也许可以同时修复 #6999。

经过一番思考，以下是我的建议：

1. 虚拟环境（bleh？）。 运行任何mach命令后，Python 将创建/激活一个虚拟环境（它将位于.pyenv/或python/.pyenv/ ）。 然后我们将根据python/requirements.txt文件安装/更新我们的依赖项）。 这将允许我们从树中删除以下内容并将它们添加为 PyPi 要求：
   
   
   
   • python/mozdebug
   
   
   • python/mozinfo
   
   
   • python/mozlog
   
   
   • dependencies/*
   
   
   • python/toml
   
   

这也将修复 #6999。 根据构建器是否在每次构建后清除工作目录，我们可能需要添加某种缓存选项或用于指定 Python virtualenv 的 mach 参数。

1. 包裹tidy.py 。 这可能意味着只创建python/tidy/tidy.py和python/tidy/setup.py 。
2. 将tidy.py合并到其他存储库中。 有几种方法可以做到这一点：
   
   
   
   1. 在 PyPi 上发布它。 除非我们创建了一个系统来在 Python 包发生变化时自动发布它，否则发布它可能会很痛苦。
   
   
   2. 拥有所有其他存储库只需执行以下操作：
   
   

pip install -e git+https://github.com/servo/servo.git#egg=servo_tidy&subdirectory=python/tidy

如果有人有任何其他想法或想法，请告诉我

我们已经有一个用于 web-platform-tests 的 virtualenv，也许它也可以用于这个。

我们已经有一个用于 web-platform-tests 的 virtualenv，也许它也可以用于这个。

好主意。 我正打算建议我们也将tests/wpt/harness (wptrunner) 从树中移出（并使其成为 pip 依赖项），但看起来您刚刚对我们的树内副本进行了一些编辑：P

上游是https://github.com/w3c/wptrunner ，在我们的副本中所做的更改应该是上游。 我不知道为什么它不是子模块或从 PyPI 安装。 但这有点偏离主题，请随意打开另一个问题。

我在想tests/wpt/_virtualenv （它是在您运行./mach test-wpt ），而不是tests/wpt/harness 。

此外，如果 _virtualenv 将执行更多任务（这很好），它可能应该在树上移得更高。

我在考虑 tests/wpt/_virtualenv （它是在你运行 ./mach test-wpt 时创建的），而不是 tests/wpt/harness。

没错，听起来不错。 生成/激活新虚拟环境的 Python 代码并不多，所以如果我们将来想要将 WPT 需求和 tidy 需求分开（由于不兼容或其他原因），应该不会那么困难。

我也不反对将 virtualenv 路径移动到更通用的地方，比如python/_virtualenv

再一次，杰克打败了我

python/_virtualenv似乎是个好地方。

由于 #6999 的分辨率，mach 现在使用python/_virtualenv 。

从它在伺服树中的位置发布包的好处是，如果我们最终将其拆分，我们将不必更改所有其他存储库； 缺点是我们必须为 pypi 管理另一组凭据，并确保推送必要的更改。

要在 pypi 上发布，某人将拥有.pypirc的副本，其中包含 pypi 帐户的用户名和密码，然后运行命令来注册和上传包。 如果在这种情况下“某人”是 buildmaster 主机，我们可以自动化更新包的过程。

话虽如此，我对 pypi 或直接安装都满意。 Pypi 现在更多的工作，直接安装在未来不确定的点上是一个更大的麻烦，两者都需要整理成一个包。

@shinglyu ，您是要保持整洁并将其设置为 Python 包，还是我要？

@edunham ：我可以做到。 :)

我的同事@askeing对这个问题很感兴趣，所以我把这个留给他。

嗨@edunham ，
我尝试在此处将其设置为 Python 包（带有测试）： https :

@askeing谢谢！ 看起来您已经完成了大部分艰苦的工作。 我唯一的挑剔是在setup.py包含setup()会有所帮助

entry_points={
        'console_scripts': [
            'servo-tidy=servo_tidy:scan',
        ],
    },

这样我们就可以在安装包后直接在另一个项目的.travis.yml的脚本部分调用servo-tidy 。

@frewsxcv @larsbergstrom @metajack你对tidy生活在伺服树和它自己的回购中有什么看法？ 保留当前树中的tidy git 历史记录对项目有多重要？ 我个人更喜欢尽可能保留历史记录，但在这种情况下，这更多地与意见有关，而不是必要性。

我没有强烈的偏好。 值得一提的是， tidy.py似乎是一些新贡献者的起点，将该文件保存在单独的存储库中可能会增加这些贡献者的障碍。

我认为最重要的问题是可以修改 tidy.py 并查看这些更改如何以尽可能少的中间步骤影响./mach test-tidy 。

糟糕，在那个 PR 中说“修复”有点扯远了。 板条箱实际上还没有在他们的 CI 中使用它。

我很确定这已经下降了，或者其他问题取代了这个问题。