Mopidy: 将 Mopidy 移植到 Python 3

创建于 2014-07-13  ·  32评论  ·  资料来源: mopidy/mopidy

Python 3 是 Python 的未来,它在部署 Mopidy 的环境中广泛可用,我对能够使用 asyncio 非常感兴趣,这需要 Python 3.3+。 Mopidy 项目之外没有任何东西可以阻止我们迁移到 Python 3。

这是跟踪我们在 Python 3 上运行 Mopidy 方式的主要错误。

  • 依赖项:

    • [x] Pykka 支持 Python 2.6+、3.2+。

    • [x] Tornado 支持 Python 2.6+、3.2+。

    • GStreamer:

    • [x] #225:将 GStreamer Python 绑定从 gst-python(仅限 Python 2)切换到 PyGI(Python 2+3)。 为了让一切都与 PyGI 一起工作,同时需要一个从 0.10 到 1.x 的 GStreamer 端口。

    • [x] #665:使混频器独立于 GStreamer,因为 GStreamer 1.x 中删除了混频器。

    • [x] #671:提取/重新实现我们的播放列表格式支持以不依赖于 GStreamer。 在 PyGI/GStreamer 1.x 之上重新实现它存在一些问题。

  • 将代码风格转向与 Python 2+3 兼容:

    • [x] flake8 警告清洁代码。

    • [x] 不再支持所有早于 2.7 的 Python 版本。

    • [x] 到处使用from __future__ import unicode_literals并用b'foo'标记二进制字符串。

    • [x] 有选择地修复2to3工具识别的可移植性问题。

  • 开发支持:

    • [x] 使用 tox 运行测试,因此我们可以轻松地添加 Python 3 测试与 Python 2.7 并行。

  • Mopidy-Spotify:

    • [x] 实现新的 libspotify 绑定,pyspotify 2,它支持 Python 2.7、3.2+。

    • [x] 在 pyspotify 2 之上重新实现 Mopidy-Spotify。

  • Mopidy-MPRIS:

    • [x] python-indicate 绑定到 libindicate 可以用 PyGI 替换。

    • [x] python-dbus 可以通过 PyGI 替换为 GDBus。

  • 扩展生态系统:

    • [x] 在 cookiecutter-mopidy-ext 中使用 tox 作为测试运行器,以便准备好开始在 Python 3 上运行测试。

    • [ ] 当 Mopidy 本身在 Python 2+3 上工作时,为所有扩展中的 Python 2+3 支持发送拉取请求/创建问题。

  • [x] 一旦~所有扩展都支持 Python 2+3,在 Mopidy 中删除 Python 2 支持。
  • [x] 删除 Python 2isms。
  • [x] 享受 Python 3 的新功能,例如 asyncio。
C-enhancement

最有用的评论

我仍然致力于将 Mopidy 移植到 Python 3。我不会让 Mopidy 在 Python 2 中消亡。

历史

将我们转移到 Python 3 的大部分工作都是在几年前完成的,以确保我们所有的依赖项都适用于 Python 3:

  • 自 2011 年从 Mopidy 中提取以来, Pykka一直与 Python 3 兼容。
  • pyspotify 2.x 是完全重写以获得 Python 3 支持和完整的 libspotify 绑定。 仅此一项就从开始到结束就花了将近两年的时间,由于 Spotify 破坏了 libspotify 的大部分,现在大部分工作都无效了。
  • Mopidy 从 GStreamer 0.10/PyGObject 到 GStreamer 1.x/PyGI 的移植,三年前在 Mopidy 2.0 中发布,是我第二次陪产假的主要项目。

正如你可能从这个问题的悠久历史和问题跟踪器的状态中读到的那样,自从我从一家大型企业工作到一家初创公司后,这个项目和一般的开源并不是我的首要任务三年前。

然而,我又开始慢慢地重新开始我的开源项目。 我当时正试图专注于一个项目,然后在进行下一个项目之前将其交付。 到目前为止, Mopidy.jsMopidy-MPRIS已经收到了一些温柔的爱和关怀。 目前,我正在开发Pykka的新版本,除其他小改进

接下来

Pykka 2 发布后,我的主要目标是将 Mopidy 迁移到 Python 3。

我不会对这项工作何时完成给出任何时间估计,因为那只会让自己陷入失败的境地。 这在很大程度上取决于外部因素和动机。

至于提供帮助,我认为没有多少新贡献者可以直接显着帮助这项工作。 我仍然没有回到以可预测和有规律的节奏从事开源工作,因此公关审查很快就会使双方失去动力。 正如前面在本期中提到的,任何有助于减少一般维护负担的方法总是间接的。

至于其他核心开发人员,我相信他们会提供帮助,但我们都有自己的优先事项和项目。 我不会等待我们的时间和动力全部一致。 如果他们在我开始使用 Mopidy 3 后加入,那就太好了,但我没有期望。

抛开我对生活和一切的胡言乱语,这既不是一项艰巨的任务,也不是我不熟悉的任务。 这主要是完成其他正在进行的事情,以便这可以成为一段时间的主要焦点。

莫比迪3

自从我在 2017 年 3 月在这里写下最后一个计划以来,Python 3 的采用已经发展到如此地步,以至于我不再认为从 Python 2 仅通过 2+3 逐步过渡到仅 Python 3 的意义。 Mopidy 2.x 已经为我们提供了三年的良好服务,无论出于何种原因,它都将是一个良好而稳定的地方,可以让那些被困在 Python 2 上的人。

于是,从2017年3月开始修改计划,我想象的过程是这样的:

  • [x] 从 Mopidy 中删除所有已弃用的内容。 有关详细问题,请参阅v3.0 里程碑
  • [x] 将 Mopidy 移植到 Python 3。
  • [x] 预发布到 PyPI,例如 3.0.0-rc1。 这不会影响那些运行pip install mopidy ,但可以运行pip install --pre mopidy来安装预发布版本以测试移植的扩展。
  • [x] 将 Mopidy 组织中的所有扩展移植到 Python 3,并可选择预发布到 PyPI。
  • [ ] 移植/帮助将其他扩展移植到 Python 3。我们到达这里后需要帮助。
  • [ ] 协调发布 Mopidy 核心和 Mopidy 组织中的所有扩展。

所有32条评论

嘿,我想帮助 Python 3 迁移,特别是正在进行的任何事情? 不想踩到任何人的脚趾

我已经在 jodal/feature/py3-compat 开始了一个分支,我在那里:

  • 更新了阻止您在 Python 3 下启动 Mopidy 的 Python 版本检查
  • 更新了 tox.ini 设置
  • 开始逐模块修复 Py3 问题,在 Python 2 和 Python 3 下运行测试

自 11 月以来,我一直没有接触过这个,除了几天前我在 Mopidy 2.0.0 之上重新建立了分支。 目前的状态是我已经修复了大约 1000 个测试,剩下大约 240 个。

未来的计划是:

  1. 逐个模块修复其余问题。
  2. 从修复所有问题中汲取经验,并尝试在 Mopidy 2.x 中尽可能多地解决问题。 我当前的逐模块方法改变了一些事情(例如,它开始威胁文件路径为 Unicode 而不是字节),我不想在 3.0 版本之前登陆 Mopidy,在那里我们被允许破坏事物。 can't-land-until-3.0 差异应该尽可能小。
  3. 将 Mopidy 与 Python 3 结合使用,查找测试未涵盖的所有问题。

好的,我会分叉出那个分支并尝试修复我能做的任何测试

大家好,有关于这个问题的消息吗?

3½ 年留给这个😉

是否有任何更新?

在使用 Mopidy 时,移植到 Python 3 是我个人的最高优先任务,问题是我去年一直忙于工作。

我目前的计划,大致顺序是:

  • [x] 修复 Mopidy-MPRIS 测试套件,使其能够经受住即将到来的变化。 这有点无聊,我家门口一英里。
  • [x] 从 Mopidy 中删除所有已弃用的内容并发布主要版本。 有关详细问题,请参阅此里程碑。 这个我很期待。
  • [x] 确保 Mopidy 组织中的所有扩展在删除后仍然有效,并进行必要的更改和发布。
  • [x] 将 Mopidy 移植到 Python 2 + 3 并发布另一个主要版本。
  • [ ] 将 Mopidy 组织中的所有扩展仅移植到 Python 3 并发布。
  • [ ] 移植/帮助将所有其他扩展移植到 Python 3 并敦促发布。
  • [ ] 从 Mopidy 本身删除 Python 2 支持。

如您所见,在开始移植之前,应该先完成几项任务。 也就是说,最大的工作已经完成:重写 pyspotify 以在 Python 3 上工作(我在这里度过了两年的业余时间)并将 Mopidy 移植到 GStreamer 1.x(在这里度过了一次陪产假)。

我会到达那里,但这需要时间。 如果人们想提供帮助,我认为最有帮助的就是在 Mopidy 支持 2+3 时帮助将端口扩展扩展到 Python 3。

感谢您的更新,@jodal。

我认为迁移到 Python3 是个好主意。

我是 mopidy 的新手,从来没有为此做出过贡献,你认为我
能帮到你吗?

El mié.,3 月 22 日。 de 2017 a la(s) 07:08, Frederick Gnodtke <
通知@github.com> escribió:

感谢您的更新, @jodal https://github.com/jodal


您收到此消息是因为您订阅了此线程。
直接回复本邮件,在GitHub上查看
https://github.com/mopidy/mopidy/issues/779#issuecomment-288352544或静音
线程
https://github.com/notifications/unsubscribe-auth/AHQMO8UqLNKzfVQZAZJ3Pnjx2N7MsHg4ks5roPMEgaJpZM4CMq8p
.

任何可以减轻一些维护负担的项目帮助都有助于实现像 Python 3 这样的大目标,因为它可以让维护者腾出时间来自己处理更大的问题或对更大的贡献进行适当的代码审查,这可以是相当费力和费时。 两个主要的例子是帮助其他用户调试他们的问题,重现可能的错误,最小化重现所需的步骤,并在问题中记录结果。

@jodal我们在哪里可以看到您使用 python3 的工作?

问候

@jodal你提到的 py3-compat 分支看起来有点......被放弃了。 某处有新的吗?
我正在考虑编写一个扩展,我更喜欢在不稳定的 mopidy 分支中挖掘一些 py3 错误,而不是记住讨厌的 py2 解决方法。

这是什么状态? 是否有可以与 python3 一起使用的 mopidy 版本?

依赖 pylast 将很快放弃对旧版 Python 2 的支持: https :

你好,
目前我在 Debian 中维护 pylast。 我打算上传不再支持 Python 2.7 的最新版本 ([1])
我计划在二月底发布这个版本,如果mopdy仍然使用Python 2将不包含在内
在下一个 Debian 版本中,这可能是一种耻辱,因为 mopidy 是一款了不起的软件 :smiley:

是否有任何官方分支机构正在发生这种情况? 我愿意帮助这件事发生

问候

@jodal扩展是这里的阻碍吗? 如果是这样,我建议针对每个扩展打开一个问题并在此处引用它们以进行跟踪。 如果您可以就可能需要进行哪些更改的问题提供一些说明,那么对 Python 不太熟悉的人(如我)仍有望有所帮助。

PS 我很乐意帮助我使用的扩展(GMusic、Iris、Podcast、Scrobbler、Spotify),我现在真的不知道该怎么做。

嘿伙计们,有人可以澄清一下适应python3的状态吗? 我们对第一个python3版本何时发布有任何估计吗? 谢谢。

我仍然致力于将 Mopidy 移植到 Python 3。我不会让 Mopidy 在 Python 2 中消亡。

历史

将我们转移到 Python 3 的大部分工作都是在几年前完成的,以确保我们所有的依赖项都适用于 Python 3:

  • 自 2011 年从 Mopidy 中提取以来, Pykka一直与 Python 3 兼容。
  • pyspotify 2.x 是完全重写以获得 Python 3 支持和完整的 libspotify 绑定。 仅此一项就从开始到结束就花了将近两年的时间,由于 Spotify 破坏了 libspotify 的大部分,现在大部分工作都无效了。
  • Mopidy 从 GStreamer 0.10/PyGObject 到 GStreamer 1.x/PyGI 的移植,三年前在 Mopidy 2.0 中发布,是我第二次陪产假的主要项目。

正如你可能从这个问题的悠久历史和问题跟踪器的状态中读到的那样,自从我从一家大型企业工作到一家初创公司后,这个项目和一般的开源并不是我的首要任务三年前。

然而,我又开始慢慢地重新开始我的开源项目。 我当时正试图专注于一个项目,然后在进行下一个项目之前将其交付。 到目前为止, Mopidy.jsMopidy-MPRIS已经收到了一些温柔的爱和关怀。 目前,我正在开发Pykka的新版本,除其他小改进

接下来

Pykka 2 发布后,我的主要目标是将 Mopidy 迁移到 Python 3。

我不会对这项工作何时完成给出任何时间估计,因为那只会让自己陷入失败的境地。 这在很大程度上取决于外部因素和动机。

至于提供帮助,我认为没有多少新贡献者可以直接显着帮助这项工作。 我仍然没有回到以可预测和有规律的节奏从事开源工作,因此公关审查很快就会使双方失去动力。 正如前面在本期中提到的,任何有助于减少一般维护负担的方法总是间接的。

至于其他核心开发人员,我相信他们会提供帮助,但我们都有自己的优先事项和项目。 我不会等待我们的时间和动力全部一致。 如果他们在我开始使用 Mopidy 3 后加入,那就太好了,但我没有期望。

抛开我对生活和一切的胡言乱语,这既不是一项艰巨的任务,也不是我不熟悉的任务。 这主要是完成其他正在进行的事情,以便这可以成为一段时间的主要焦点。

莫比迪3

自从我在 2017 年 3 月在这里写下最后一个计划以来,Python 3 的采用已经发展到如此地步,以至于我不再认为从 Python 2 仅通过 2+3 逐步过渡到仅 Python 3 的意义。 Mopidy 2.x 已经为我们提供了三年的良好服务,无论出于何种原因,它都将是一个良好而稳定的地方,可以让那些被困在 Python 2 上的人。

于是,从2017年3月开始修改计划,我想象的过程是这样的:

  • [x] 从 Mopidy 中删除所有已弃用的内容。 有关详细问题,请参阅v3.0 里程碑
  • [x] 将 Mopidy 移植到 Python 3。
  • [x] 预发布到 PyPI,例如 3.0.0-rc1。 这不会影响那些运行pip install mopidy ,但可以运行pip install --pre mopidy来安装预发布版本以测试移植的扩展。
  • [x] 将 Mopidy 组织中的所有扩展移植到 Python 3,并可选择预发布到 PyPI。
  • [ ] 移植/帮助将其他扩展移植到 Python 3。我们到达这里后需要帮助。
  • [ ] 协调发布 Mopidy 核心和 Mopidy 组织中的所有扩展。

由于已经有五个月了,我想是时候更新这个问题了。 我上次提到的 Pykka 版本是六周前作为 Pykka 2.0 发布的。 从那以后,我又开始研究 Mopidy:

  • 错误修复版本 2.2.3 已发布,因此我们目前在release-2.2分支中没有任何未发布的内容。
  • 在将成为 Mopidy 3.0 的develop分支中,大部分已弃用的内容已被删除。

接下来对我来说可能是:

  • [x] 简化日志记录 (#1452)
  • [x] 在从面向字节的 Python 2 API 迁移到面向文本的 Python 3 文件系统 API 时,决定并实现如何处理文件系统路径。 (尚无跟踪此问题的问题。)
  • [x] 开始让测试套件通过 Python 3。

我可以做些什么来帮助制作 mopidy 核心或 mopidy-soundcloud 插件与 python3 一起工作?

感谢您到目前为止的工作@jodal!

我想知道,在使用 Python 3 版本的 Sphinx 构建文档(要求打包)时,我们应该如何安装文档?

我曾经做make -C docs SPHINXBUILD=sphinx-build-2 man但将其更改为sphinx-build-3只是错误:

make: Entering directory '/home/builder/aports/community/mopidy/src/Mopidy-3.0.0a1/docs'
sphinx-build-3 -b man -d _build/doctrees   . _build/man
Running Sphinx v1.8.4

Configuration error:
The configuration file (or one of the modules it imports) called sys.exit()

这发生在 2.2.3 和 3.0.0a1 上。 或者这部分还没有移植?

鉴于 v3 无论如何都会破坏向后兼容性,并且 python2 将在 1 月终止,是否有理由在 v3 中保持 python2 兼容性?

@tmccombs说:

鉴于 v3 无论如何都会破坏向后兼容性,并且 python2 将在 1 月终止,是否有理由在 v3 中保持 python2 兼容性?

不,我们不打算在 Mopidy 3 中保持 Python 2 的兼容性。

引用自二月的我自己:

自从我在 2017 年 3 月在这里写下最后一个计划以来,Python 3 的采用已经发展到如此地步,以至于我不再认为从 Python 2 仅通过 2+3 逐步过渡到仅 Python 3 的意义。 Mopidy 2.x 已经为我们提供了三年的良好服务,无论出于何种原因,它都将是一个良好而稳定的地方,可以让那些被困在 Python 2 上的人。

@PureTryOut说:

这发生在 2.2.3 和 3.0.0a1 上。 或者这部分还没有移植?

Mopidy 还没有移植到 Python 3。 我们刚刚进行了其他简化并删除了不推荐使用的内容,以使转换更容易。 移植后,我们将使用在 Python 3 上运行的 Sphinx 构建文档。

我可以建议确保下一个版本(2.4.0?)与 Python 3 兼容吗? 大多数发行版都在努力摆脱他们的 Python 2 包。 就我而言,Alpine Linux 将在下一个版本(3.11,明年 1 月底)之前删除 Python 2,这意味着如果届时与 Python 3 不兼容,Mopidy 将从存储库中删除。

Mopidy 3.0 将与 Python 3 兼容。计划是在年底前推出。

@jodal ,在接下来的几周内我可能会有一些空闲周期来帮助实现一些 Python 3 功能。 直接在 mopidy 中或在扩展中。 你有什么特别的问题要解决吗?

嗨@zubieta!

我们最近合并了一个测试设置,它成功地在 Python 3 上运行了大约 10% 的测试套件。很快就会合并几个 PR,将其增加到大约 20%。 请检查哪些 PR 已经打开,这样您就不会重复任何工作,并查看 #1809 的描述以获取有关如何移植更多模块及其测试的分步指南。

一旦 Mopidy 核心在 Python 3 上运行,扩展就会随之而来。

我认为是时候更新 Mopidy 和 Python 3 的状态了……

Mopidy 3.0.0a2 在 Python 3 上运行:tada:

Mopidy 测试套件中 2016 年的每一个测试现在都可以在 Python 2.7 和 Python 3.7 上运行。 所有这些工作都合并在develop分支中。 非常感谢@kingosticks帮助进行移植工作!

我刚刚将develop分支作为Mopidy 3.0.0a2 发布到 PyPI。 它可以通过以下方式安装:

python3.7 -m pip install --pre mopidy

除了通过测试套件、通过 MPD 和 HTTP 回答一些请求以及播放少量 MP3 文件之外,此版本没有经过任何广泛的测试。

前方道路:arrow_right:

Mopidy 3.0.0a2 可能是唯一一个同时支持 Python 2 和 3 的 Mopidy 版本。我们将立即开始移除 Python 2.7 支持并使 Mopidy 成为一个更干净、更现代的 Python 代码库。

最终版本的计划大致如下:

  • [x] 从 Mopidy 中删除 Python 2.7 支持并在移植工作后进行清理。
  • [x] 确保支持 Python 3.8。
  • [x] 用黑色格式化源代码。
  • [x] 发布另一个alpha版本。
  • [] 修复v3.0 里程碑中的问题。
  • [ ] 发布测试版。
  • [ ] 修复通过使用和移植扩展发现的任何错误。
  • []发布候选版本
  • [ ] 一旦移植了足够多的扩展集...
  • [] 发布 Mopidy 3.0最终版

需要帮助 :heart_eyes:

在迈向 3.0 最终版的同时,我们需要在 PyPI 上通过搜索“mopidy”找到的帮助

对于您关心的每个扩展:

  • [] 移植到 Python >= 3.7。 删除 Python 2.7 支持。
  • [] 考虑从扩展 cookiecutter 中包含项目设置现代化。 一旦我开始自己移植一些扩展,我将很快更新 cookiecutter。
  • [ ] 将端口预发布到 PyPI。
  • [ ] Mopidy 3.0 final 发布后,将最终版本发布到 PyPI。

76 次提交,204 个文件更改,9832 次插入(+),9612 次删除(-)之后,我们还有另一个预发布:Mopidy 3.0.0a3 现在在 PyPI 上。 它可以通过以下方式安装:

python3 -m pip install --pre mopidy

自 3.0.0a2 以来的新功能:

  • Python 2.7 支持消失了,包括许多遗留/兼容代码:

    • mopidy.compat模块不见了。

    • # encoding: utf-8评论不见了。

    • from __future__ ...进口消失了。

    • object所有子类都消失了。

    • .encode().decode()不再包含显式的"utf-8"参数。

  • 源代码格式为black 。 :black_heart:
  • isort现在已配置,可在需要时用于清理导入。
  • mock被替换为unittest.mock
  • unittest 断言方法替换为 pytest assert语句,这意味着更好的可读性和更好的错误消息。
  • %.format()大多数实例都替换为 f 字符串。
  • 所有 linter 都在 Python 3 上运行。
  • 文档建立在 Python 3 之上。
  • 除了 Python 3.7 之外,CI 中的测试还可以在 Python 3.8 上运行。
  • setup.py已被最小化并替换为声明性的setup.cfg
  • tox.inidev-requirements.txtdocs/requirements.txt中的依赖项都被setup.cfg “额外”替换。 这意味着开发依赖项现在与python3 -m pip install -e ".[dev]"

前面的道路看起来仍然像我在之前的评论中起草的那样。

关于 Mopidy 核心,我想我们已经完成了。

Mopidy 3.0 最终版的其余部分在 v3.0 里程碑中进行跟踪:
https://github.com/mopidy/mopidy/milestone/55

在此项目板上跟踪关键扩展到 Python 3 的移植:
https://github.com/orgs/mopidy/projects/2

如果您在不久的将来在 Python 3 上测试 Mopidy,请为您遇到的任何问题打开问题!

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

ecoCuyo picture ecoCuyo  ·  3评论

zopyx picture zopyx  ·  4评论

flyingrub picture flyingrub  ·  15评论

mczerski picture mczerski  ·  9评论

jodal picture jodal  ·  13评论