Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On Wednesday 03 March 2010 03:47:37 Tomáš Chvátal wrote: Dne 3.3.2010 08:52, Ryan Hill napsal(a): On Wed, 03 Mar 2010 08:52:55 +0200 Petteri Räty wrote: On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote: Members of Gentoo Python Project have agreed to deprecate the following functions in EAPI =2: - python_version() - python_mod_exists() - python_tkinter_exists() - distutils_python_version() - distutils_python_tkinter() These functions are already banned in EAPI =3. 1. In this week, these functions will start printing deprecation warnings in older EAPIs. 2. On 2010-07-01, these functions will start calling die(). (If any ebuilds in gentoo-x86 still call any of these functions on 2010-07-01, then addition of calls to die() will be delayed.) 3. On 2011-01-01, these functions will be removed. Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. ?! since when? Since ever. If you change eclass abi you need to rename it. erm, no. being anal about eclass removal is only because of the breakage that occurred with installed packages. functions that get used at build time are free to be deprecated on the fly. Arfrever has a sane set of steps that should ease transition of everything in tree. anything out of tree (overlays) that dont adapt deserve to die anyways. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On Friday 05 March 2010 15:14:33 Ryan Hill wrote: On Fri, 05 Mar 2010 13:12:36 +0200 Petteri Räty wrote: Because there is so little benefit from removing old functions. What is so bad about having them grouped at the bottom of the file inside a deprecated section? Because then people use them. Don't ask me why. I have things I deprecated over two years ago still being used by a dozen ebuilds bumped within the last three months. You should be familiar with this behaviour wrt. built_with_use. So, when I'm making changes I still have to maintain the deprecated stuff. If I really want to get rid of it, then I have to break it. Replace the whole thing with a eerror like any of our deprecated eclasses. At that point, I would rather just remove the function or eclass than curate a museum of dead interfaces. But I suppose that's a personal quirk -- I hate having old unused code around. indeed ... and to take it further, ive seen devs inclined to leave ebuilds alone even after they were told point blank the funcs were deprecated and going away. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On 03/05/2010 10:14 PM, Ryan Hill wrote: Because then people use them. Don't ask me why. I have things I deprecated over two years ago still being used by a dozen ebuilds bumped within the last three months. You should be familiar with this behaviour wrt. built_with_use. So, when I'm making changes I still have to maintain the deprecated stuff. built_with_use isn't using eerror and it wasn't scanned by repoman so unless you read the whole ebuild you could miss it when bumping. If we have devs ignoring eerrors out of the ebuild, then we should rather get rid of them. It's much harder to spot you are using a deprecated function when it doesn't exist at all as then the error message during emerge doesn't stand out in any form. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On Thu, 04 Mar 2010, Petteri Räty wrote: I think removal of functions is a special case of Adding and Updating Eclasses and we already have a policy for this. Removing functions needs a migration plan. For example how long to have a warning there, how long before it can be removed etc. There may be no general answer to these questions. If it's an eclass with limited scope and if the functions are no longer used in the tree, then I don't see the need for a long transition period. OTOH, for widespread eclasses like eutils you'd probably want it. I don't see how you can get those from the common policy? If you don't email gentoo-dev first, and end up breaking something, expect to be in a lot of trouble. Ulrich
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 3.3.2010 08:52, Ryan Hill napsal(a): On Wed, 03 Mar 2010 08:52:55 +0200 Petteri Räty betelge...@gentoo.org wrote: On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote: Members of Gentoo Python Project have agreed to deprecate the following functions in EAPI =2: - python_version() - python_mod_exists() - python_tkinter_exists() - distutils_python_version() - distutils_python_tkinter() These functions are already banned in EAPI =3. 1. In this week, these functions will start printing deprecation warnings in older EAPIs. 2. On 2010-07-01, these functions will start calling die(). (If any ebuilds in gentoo-x86 still call any of these functions on 2010-07-01, then addition of calls to die() will be delayed.) 3. On 2011-01-01, these functions will be removed. Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. ?! since when? Since ever. If you change eclass abi you need to rename it. Tom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuOIikACgkQHB6c3gNBRYdIoQCfXZupVWgQByemjTLbSyN6qH+H L3IAn2yFop+l4dclIyzoCYdlGK0a/xSn =iutE -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
2010/3/3 Tomáš Chvátal scarab...@gentoo.org: Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. ?! since when? Since ever. If you change eclass abi you need to rename it. I think you can *add* functions and variables to eclasses, you can change *how* a function works internally, you can *fix* problems with functions (which would technically result in a change in API). I don't think it has ever been as strict as, say, the kernel ABI interface. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On 3.3.2010 11.23, Nirbheek Chauhan wrote: 2010/3/3 Tomáš Chvátal scarab...@gentoo.org: Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. ?! since when? Since ever. If you change eclass abi you need to rename it. I think you can *add* functions and variables to eclasses, you can change *how* a function works internally, you can *fix* problems with functions (which would technically result in a change in API). I don't think it has ever been as strict as, say, the kernel ABI interface. Yes, eclasses go along the same lines as shared libraries, which is probably what Tomáš meant any way. Regards, Petteri
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 03 Mar 2010 09:47:37 +0100 Tomáš Chvátal scarab...@gentoo.org wrote: Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. since when? Since ever. If you change eclass abi you need to rename it. No, that's not been the case 'since ever' at all. It used to be that if you changed or removed a function, you just had to make sure you didn't break anything. This was made more complicated by the way that eclasses in the tree were used for removing installed packages too, which is no longer an issue. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkuOWnAACgkQ96zL6DUtXhHcgACgj8hDz+sIgvCbqXeotvUqHyYr v2wAoJzESPARQnPDaWhrbFNiK0zHp2G2 =RzSg -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On 03/03/2010 02:47 PM, Ciaran McCreesh wrote: On Wed, 03 Mar 2010 09:47:37 +0100 Tomáa Chvátal scarab...@gentoo.org wrote: Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. since when? Since ever. If you change eclass abi you need to rename it. No, that's not been the case 'since ever' at all. It used to be that if you changed or removed a function, you just had to make sure you didn't break anything. This was made more complicated by the way that eclasses in the tree were used for removing installed packages too, which is no longer an issue. You can't fix all possible overlays so you can only start removing functions that are used for installations if we decide we don't care about overlays. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On 03/03/2010 02:40 PM, Ryan Hill wrote: On Wed, 03 Mar 2010 13:09:49 +0200 Petteri Räty betelge...@gentoo.org wrote: On 3.3.2010 11.23, Nirbheek Chauhan wrote: 2010/3/3 Tomáš Chvátal scarab...@gentoo.org: Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. ?! since when? Since ever. If you change eclass abi you need to rename it. I think you can *add* functions and variables to eclasses, you can change *how* a function works internally, you can *fix* problems with functions (which would technically result in a change in API). I don't think it has ever been as strict as, say, the kernel ABI interface. Yes, eclasses go along the same lines as shared libraries, which is probably what Tomáš meant any way. Is this actually documented anywhere? Or is this another of our this-is-policy-because-everyone-knows-it's-policy policies? I know there was a technical issue with removing pkg_*_rm functions way-back-when, but if there's no technical reason why functions can't be deprecated, and we're just clinging to policy in the name of policy, then I can't say I see the point. Big eclass changes should go through gentoo-dev so someone here will point it out at least. Devmanual should document it so I challenge anyone to submit a patch: http://devmanual.gentoo.org/eclass-writing/index.html git+ssh://git.gentoo.org/var/gitroot/devmanual.git Also policies should be changed when they don't make sense any more as I said in my first response but I am not sure if that's the case here. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On 03/03/2010 11:39 PM, Ryan Hill wrote: Also policies should be changed when they don't make sense any more as I said in my first response but I am not sure if that's the case here. The problem is I don't think this is actually a policy. One of the first projects I did as a developer, while still under probation, was a complete rewrite, in-place, of an eclass. Many functions were removed or renamed (done in an overlay of course, with a migration path). It was fully reviewed, on list, by senior devs at the time. I was told by several people that if there were any exported pkg_post_rm or pkg_pre_rm functions, they couldn't be touched because of portage limitations (those limitations were removed ~3 years ago now IIRC). So I wonder if this isn't just a years-long game of Telephone where one rule passed down by word of mouth got over-generalized and sufficiently twisted as to apply to everything. You can mostly get away with deprecating eclass functions in a slowly manner. Nor do I think it's a particularly useful policy that keeps deprecated interfaces around forever. Careful removal with a long warning period shouldn't actually pose a problem. I think Arfrever's plan is reasonable. If we decide allowing removal of functions, we should come up with a common procedure like the eclass removal policy: http://devmanual.gentoo.org/eclass-writing/index.html Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On Thu, 04 Mar 2010, Petteri Räty wrote: If we decide allowing removal of functions, we should come up with a common procedure like the eclass removal policy: http://devmanual.gentoo.org/eclass-writing/index.html I think removal of functions is a special case of Adding and Updating Eclasses and we already have a policy for this. Ulrich
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On 03/04/2010 09:39 AM, Ulrich Mueller wrote: On Thu, 04 Mar 2010, Petteri Räty wrote: If we decide allowing removal of functions, we should come up with a common procedure like the eclass removal policy: http://devmanual.gentoo.org/eclass-writing/index.html I think removal of functions is a special case of Adding and Updating Eclasses and we already have a policy for this. Ulrich Removing functions needs a migration plan. For example how long to have a warning there, how long before it can be removed etc. I don't see how you can get those from the common policy? Regards, Petteri signature.asc Description: OpenPGP digital signature
