Bug 458794 – app-editors/*vim: python-r1 conversion

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Michał Górny 2013-02-22 21:56:31 UTC]

It seems that vim ebuilds are using vim.eclass to handle python.eclass deps. Please decide how should I proceed with replacing the python.eclass use with the new eclasses.

As far as I can see, we have the following possibilities:

1) just modify the eclass -- will 'just work' but also affects stable ebuilds.

2) bind eclass change to VIM_VERSION -- probably the cleanest option, requires waiting for 7.4.

3) add a variable for eclass change -- ugly TBH. however, we could remove the variable when 'new' ebuilds go stable and last of the 'old' ones is removed.

4) fork the eclass into -r1 -- seems like an overkill.

[Comment 1 Arfrever Frehtes Taifersar Arahesis 2013-02-22 22:44:08 UTC]

Remember that Vim supports both Python 2 and 3, but at most one version of Python 2 and at most one version of Python 3. See bug #333059.

[Comment 2 Michał Górny 2013-02-23 00:13:20 UTC]

Note to self: radhermit suggested using EAPI for that.

[Comment 3 Michał Górny 2013-02-23 22:52:49 UTC]

Created attachment 339870 [details, diff]
1) move EAPI check earlier

It's cleaner to first validate EAPI and then rely on its value.

[Comment 4 Michał Górny 2013-02-23 22:53:29 UTC]

Created attachment 339872 [details, diff]
2) Disable inheriting python.eclass in vim-core

The global inherit would collide with conditional python-r1, and python is not used in vim-core.

[Comment 5 Michał Górny 2013-02-23 22:53:57 UTC]

Created attachment 339874 [details, diff]
3) Remove unused EAPI 2 code blocks

Last piece of clean up before introducing the new code.

[Comment 6 Michał Górny 2013-02-23 23:00:20 UTC]

Created attachment 339880 [details, diff]
4) Use python-r1

Now a few notes:

- python-r1 is enabled in EAPI=5. In that EAPI, HAVE_PYTHON_R1 is declared (similarly to what EAPI 2/3 did in the paste).

- PYTHON_COMPAT needs to be set in the ebuild before inheriting the eclass.

- REQUIRED_USE enforces that with USE=python at least one Python implementation is selected, and at most one version of Python 2 & Python 3.

- src_configure() checks the enabled versions and sets configure appropriately. There's no need for pkg_setup() like python.eclass did.

- as noted in bug 333059, the python3 checks are broken with python3.2+. I'm not really into hacking this over since it's a lot of hackery logic that doesn't fit the eclass, and it has to be fixed finally upstream anyway.

You can either delay the conversion until upstream-fixed version hits the tree, or just commit one with PYTHON_COMPAT=( python{2_5,2_6,2_7,3_1} ), so that people with 3.2+ won't have Python3 enabled for now.

[Comment 7 Michał Górny 2013-02-23 23:01:55 UTC]

Created attachment 339882 [details, diff]
Example diff of an ebuild

[Comment 8 Michał Górny 2013-03-14 17:22:59 UTC]

Ping. Almost three weeks have passed and still no response.

[Comment 9 Tim Harder 2013-04-21 23:38:18 UTC]

Patches look ok and applied to CVS, thanks.