PyMaemo/Python 2.6 porting guide - Revision history

imported_>amigadave: tidy

2010-06-23T12:13:30Z

tidy

← Older revision		Revision as of 12:13, 23 June 2010
Line 1:		Line 1:
	~~== Python 2.6 Porting Guide ==~~		{{out of date}}

	<b style="color: red">Important: this document is still a draft. There are currently no planned dates for migration to 2.6, but it will be informed in advance on the maemo-developers and pymaemo-developers mailing lists, so that developers have some time to fix their packages.</b>		<b style="color: red">Important: this document is still a draft. There are currently no planned dates for migration to 2.6, but it will be informed in advance on the maemo-developers and pymaemo-developers mailing lists, so that developers have some time to fix their packages.</b>
Line 5:		Line 5:
	This documents contains some general guidelines about how to port your Python application currently being used with Python 2.5 for working without problems with Python 2.6.		This documents contains some general guidelines about how to port your Python application currently being used with Python 2.5 for working without problems with Python 2.6.

	=== Introduction ===		== Introduction ==

	Currently, Maemo 4.x (Diablo) has Python 2.5. Maemo 5 ~~Beta~~ (Fremantle) has this same version, but we are evaluating upgrading Fremantle to Python 2.6, so that developers can use the latest features, while keeping compatibility with Python 2.5. See the [http://docs.python.org/whatsnew/2.6.html What’s New in Python 2.6] page for details.		Currently, Maemo 4.x (Diablo) has Python 2.5. Maemo 5 (Fremantle) has this same version, but we are evaluating upgrading Fremantle to Python 2.6, so that developers can use the latest features, while keeping compatibility with Python 2.5. See the [http://docs.python.org/whatsnew/2.6.html What’s New in Python 2.6] page for details.

	This also means that we have no plans to migrate to Python 3.x during Fremantle life cycle. Using Python 2.6 is the best option because developers can use most 3.x features without breaking compatibility with Python 2.5. With Python 2.6, users can use a flag to check for possible incompatibilities with Python 3.x.		This also means that we have no plans to migrate to Python 3.x during Fremantle life cycle. Using Python 2.6 is the best option because developers can use most 3.x features without breaking compatibility with Python 2.5. With Python 2.6, users can use a flag to check for possible incompatibilities with Python 3.x.

	One question might arise: why not have both 2.6 and 3.x, or even 2.5, 2.6 and 3.x? We have thought about this, the problem is, with the current mechanism used in Debian and Ubuntu (which we also use), packages that install Python extensions need to be compiled for all supported versions, and all resulting binaries are installed ~~<b>~~in a single package~~</b>~~. This means that some packages will simply double or triple their size even if only one version is installed and used.		One question might arise: why not have both 2.6 and 3.x, or even 2.5, 2.6 and 3.x? We have thought about this, the problem is, with the current mechanism used in Debian and Ubuntu (which we also use), packages that install Python extensions need to be compiled for all supported versions, and all resulting binaries are installed ''in a single package''. This means that some packages will simply double or triple their size even if only one version is installed and used.

	Besides, if we have two or three versions available in the repository, there is a possibility that some packages would depend on e.g. 2.5 while others depend 3.x. So the user would need to have ~~<b>~~both~~</b>~~ versions installed in some cases.		Besides, if we have two or three versions available in the repository, there is a possibility that some packages would depend on e.g. 2.5 while others depend 3.x. So the user would need to have ''both'' versions installed in some cases.

	For small devices such as the Internet Tablets, saving space is also a high priority, so we decided to support only a single version at a time during the life cycle of a Maemo distribution.		For small devices such as the Internet Tablets, saving space is also a high priority, so we decided to support only a single version at a time during the life cycle of a Maemo distribution.
Line 30:		Line 30:

	* Any paths that, for some reason, have hardcoded "python2.5" or "site-packages" will have to be changed to "python2.6" and "dist-packages", as these are the ones used on Python 2.6.		* Any paths that, for some reason, have hardcoded "python2.5" or "site-packages" will have to be changed to "python2.6" and "dist-packages", as these are the ones used on Python 2.6.
			* If you use distutils for building your package, you must pass the --install-layout=deb flag for "setup.py install" command inside debian/rules in order to install the files to the proper locations. If you're using CDBS for this task, use the variable DEB_PYTHON_INSTALL_ARGS_ALL for passing the flag, e.g.:<pre>DEB_PYTHON_INSTALL_ARGS_ALL = --no-compile -O0 --install-layout=deb</pre>
	* If you use distutils for building your package, you must pass the --install-layout=deb flag for "setup.py install" command inside debian/rules in order to install the files to the proper locations. If you're using CDBS for this task, use the variable DEB_PYTHON_INSTALL_ARGS_ALL for passing the flag, e.g.:

	::DEB_PYTHON_INSTALL_ARGS_ALL = --no-compile -O0 --install-layout=deb

	* If your application uses any python2.5 package as one of its dependencies in any Depends field, you should drop the version number and add the version as a requirement - for example, python2.5 can be changed to python (>= 2.5) without problems. If this is not possible nor desired, just change the dependencies to python2.6.		* If your application uses any python2.5 package as one of its dependencies in any Depends field, you should drop the version number and add the version as a requirement - for example, python2.5 can be changed to python (>= 2.5) without problems. If this is not possible nor desired, just change the dependencies to python2.6.

	* Also, this would be a good time for your package to use dependencies that follow the new Debian Python Policy, if that's the case - the Policy states that Python packages must not have a fixed version number on its name (e.g. prefer python-xml instead of python2.6-xml).		* Also, this would be a good time for your package to use dependencies that follow the new Debian Python Policy, if that's the case - the Policy states that Python packages must not have a fixed version number on its name (e.g. prefer python-xml instead of python2.6-xml).

	* One very particular case where changes are required is when some Python script uses identifies that became reserved keywords in Python 2.6. Old versions of python-xml had this issue, where the "as" identifier (which became a reserved keyword in Python 2.6) was being used as variable name in some places. If these occurrences are not replaced, running the script will result in syntax errors.		* One very particular case where changes are required is when some Python script uses identifies that became reserved keywords in Python 2.6. Old versions of python-xml had this issue, where the "as" identifier (which became a reserved keyword in Python 2.6) was being used as variable name in some places. If these occurrences are not replaced, running the script will result in syntax errors.

	[[Category:Python]]		[[Category:Python]]

imported_>amigadave: Category:Python

2010-02-11T15:52:58Z

Category:Python

← Older revision		Revision as of 15:52, 11 February 2010
Line 40:		Line 40:

	* One very particular case where changes are required is when some Python script uses identifies that became reserved keywords in Python 2.6. Old versions of python-xml had this issue, where the "as" identifier (which became a reserved keyword in Python 2.6) was being used as variable name in some places. If these occurrences are not replaced, running the script will result in syntax errors.		* One very particular case where changes are required is when some Python script uses identifies that became reserved keywords in Python 2.6. Old versions of python-xml had this issue, where the "as" identifier (which became a reserved keyword in Python 2.6) was being used as variable name in some places. If these occurrences are not replaced, running the script will result in syntax errors.

			[[Category:Python]]

imported_>dneary: PyMaemo/Python26PortingGuide moved to PyMaemo/Python 2.6 porting guide: Naming convention - no CamelCase

2010-01-29T16:10:30Z

PyMaemo/Python26PortingGuide moved to PyMaemo/Python 2.6 porting guide: Naming convention - no CamelCase

← Older revision	Revision as of 16:10, 29 January 2010
(No difference)

imported_>lizardo at 15:40, 23 June 2009

2009-06-23T15:40:25Z

← Older revision		Revision as of 15:40, 23 June 2009
Line 38:		Line 38:

	* Also, this would be a good time for your package to use dependencies that follow the new Debian Python Policy, if that's the case - the Policy states that Python packages must not have a fixed version number on its name (e.g. prefer python-xml instead of python2.6-xml).		* Also, this would be a good time for your package to use dependencies that follow the new Debian Python Policy, if that's the case - the Policy states that Python packages must not have a fixed version number on its name (e.g. prefer python-xml instead of python2.6-xml).

			* One very particular case where changes are required is when some Python script uses identifies that became reserved keywords in Python 2.6. Old versions of python-xml had this issue, where the "as" identifier (which became a reserved keyword in Python 2.6) was being used as variable name in some places. If these occurrences are not replaced, running the script will result in syntax errors.

imported_>lizardo: /* Python 2.6 porting guidelines */

2009-06-19T13:59:06Z

Python 2.6 porting guidelines

← Older revision		Revision as of 13:59, 19 June 2009
Line 19:		Line 19:
	=== Python 2.6 porting guidelines ===		=== Python 2.6 porting guidelines ===

	Porting a package to support Python 2.6 usually involves actually making it version agnostic. In Maemo versions prior to Fremantle, the packages had hardcoded support for Python 2.5, which can be demonstrated by all Python binding packages having "python2.5-" as prefix, and consequently ~~the~~ Python ~~application~~ also had these names on ~~the~~ Depends ~~field~~.		Porting a package to support Python 2.6 usually involves actually making it version agnostic. In Maemo versions prior to Fremantle, the packages had hardcoded support for Python 2.5, which can be demonstrated by all Python binding packages having "python2.5-" as prefix, and consequently Python applications also had these names on their Depends fields in debian/control.

	As long as Fremantle contains Python 2.5, though, packages that worked on Diablo should also work on Fremantle without changes. This happens because PyMaemo packages named python-<something> can also be installed by using python2.5-<something>.		As long as Fremantle contains Python 2.5, though, packages that worked on Diablo should also work on Fremantle without changes. This happens because PyMaemo packages named python-<something> can also be installed by using python2.5-<something>.

	On the other hand, if we indeed upgrade to Python 2.6, this compatibility will not work anymore, and ~~the~~ packages will ~~be required to be modified~~ so they can work on Fremantle.		On the other hand, if we indeed upgrade to Python 2.6, this compatibility will not work anymore, and packages will need modifications so they can work on Fremantle.

	One possibility we are evaluating is to provide updates to PyMaemo packages in previous Maemo releases (e.g. chinook and diablo) so they can also be installed by using the version agnostic python-<something> name. This would allow most packages to be uploaded to all three releases (chinook, diablo and fremantle) without requiring specific changes only for Fremantle.		One possibility we are evaluating is to provide updates to PyMaemo packages in previous Maemo releases (e.g. chinook and diablo) so they can also be installed by using the version agnostic python-<something> name (along the old python2.5-<something> names). This would allow most packages to be uploaded to all three releases (chinook, diablo and fremantle) without requiring specific changes only for Fremantle.

	=== Porting tips ===		=== Porting tips ===

imported_>lizardo: /* Introduction */

2009-06-19T13:56:40Z

Introduction

← Older revision		Revision as of 13:56, 19 June 2009
Line 7:		Line 7:
	=== Introduction ===		=== Introduction ===

	Currently, Maemo 4.x (Diablo) has Python 2.5. Maemo 5 Beta (Fremantle) ~~also~~ has ~~2.5~~, but we are evaluating upgrading Fremantle to 2.6, so that developers can use the latest features, while keeping compatibility with Python 2.5. See the [http://docs.python.org/whatsnew/2.6.html What’s New in Python 2.6] page for details.		Currently, Maemo 4.x (Diablo) has Python 2.5. Maemo 5 Beta (Fremantle) has this same version, but we are evaluating upgrading Fremantle to Python 2.6, so that developers can use the latest features, while keeping compatibility with Python 2.5. See the [http://docs.python.org/whatsnew/2.6.html What’s New in Python 2.6] page for details.

	This also means that we have no plans to migrate to Python 3.x in Fremantle. Using Python 2.6 is the best option because developers can use most 3.x features without breaking compatibility with Python 2.5.		This also means that we have no plans to migrate to Python 3.x during Fremantle life cycle. Using Python 2.6 is the best option because developers can use most 3.x features without breaking compatibility with Python 2.5. With Python 2.6, users can use a flag to check for possible incompatibilities with Python 3.x.

	One question might arise: why not have both 2.6 and 3.x, or even 2.5, 2.6 and 3.x? We have thought about this, the problem is, in the current mechanism used in Debian and Ubuntu (~~that~~ we also use), ~~the~~ packages that install Python extensions need to be compiled for all supported versions, and all ~~these versions~~ are installed <b>in a single package</b>. This means that some packages will simply double or triple their size even if only one version is installed.		One question might arise: why not have both 2.6 and 3.x, or even 2.5, 2.6 and 3.x? We have thought about this, the problem is, with the current mechanism used in Debian and Ubuntu (which we also use), packages that install Python extensions need to be compiled for all supported versions, and all resulting binaries are installed <b>in a single package</b>. This means that some packages will simply double or triple their size even if only one version is installed and used.

	Besides, if we have two or three versions available in the repository, there is a possibility that some packages depend on e.g. 2.5 while others depend 3.x. So the user would need to have <b>both</b> versions installed in some cases.		Besides, if we have two or three versions available in the repository, there is a possibility that some packages would depend on e.g. 2.5 while others depend 3.x. So the user would need to have <b>both</b> versions installed in some cases.

	For small devices as the Internet Tablets, saving space is also a high priority, so we decided to support a single version during the life cycle of ~~the~~ distribution.		For small devices such as the Internet Tablets, saving space is also a high priority, so we decided to support only a single version at a time during the life cycle of a Maemo distribution.

	<b>~~FINISH ME~~</b>		=== Python 2.6 porting guidelines ===

			Porting a package to support Python 2.6 usually involves actually making it version agnostic. In Maemo versions prior to Fremantle, the packages had hardcoded support for Python 2.5, which can be demonstrated by all Python binding packages having "python2.5-" as prefix, and consequently the Python application also had these names on the Depends field.

			As long as Fremantle contains Python 2.5, though, packages that worked on Diablo should also work on Fremantle without changes. This happens because PyMaemo packages named python-<something> can also be installed by using python2.5-<something>.

			On the other hand, if we indeed upgrade to Python 2.6, this compatibility will not work anymore, and the packages will be required to be modified so they can work on Fremantle.

			One possibility we are evaluating is to provide updates to PyMaemo packages in previous Maemo releases (e.g. chinook and diablo) so they can also be installed by using the version agnostic python-<something> name. This would allow most packages to be uploaded to all three releases (chinook, diablo and fremantle) without requiring specific changes only for Fremantle.

			=== Porting tips ===

			* Any paths that, for some reason, have hardcoded "python2.5" or "site-packages" will have to be changed to "python2.6" and "dist-packages", as these are the ones used on Python 2.6.

	* Any paths that, for some reason, must have hardcoded "python2.5" or "site-packages" will have to be changed to "python2.6" and "dist-packages", as these are the ones used on Python 2.6.
	* If you use distutils for building your package, you must pass the --install-layout=deb flag for "setup.py install" command inside debian/rules in order to install the files to the proper locations. If you're using CDBS for this task, use the variable DEB_PYTHON_INSTALL_ARGS_ALL for passing the flag, e.g.:		* If you use distutils for building your package, you must pass the --install-layout=deb flag for "setup.py install" command inside debian/rules in order to install the files to the proper locations. If you're using CDBS for this task, use the variable DEB_PYTHON_INSTALL_ARGS_ALL for passing the flag, e.g.:

	::DEB_PYTHON_INSTALL_ARGS_ALL = --no-compile -O0 --install-layout=deb		::DEB_PYTHON_INSTALL_ARGS_ALL = --no-compile -O0 --install-layout=deb

	* If your application uses any python2.5 package as one of its dependencies in any Depends field, you should drop the version number and add the version as a requirement - ~~as a~~ example, python2.5 can be changed to python (>= 2.5) without problems. If this is not possible/desired, just change the dependencies to python2.6.		* If your application uses any python2.5 package as one of its dependencies in any Depends field, you should drop the version number and add the version as a requirement - for example, python2.5 can be changed to python (>= 2.5) without problems. If this is not possible nor desired, just change the dependencies to python2.6.

	* Also, this would be a good time for your package to use dependencies that follow the new Debian Python Policy, if that's the case - the Policy states that Python packages must not have a fixed version number on its name (e.g. prefer python-xml instead of python2.6-xml).		* Also, this would be a good time for your package to use dependencies that follow the new Debian Python Policy, if that's the case - the Policy states that Python packages must not have a fixed version number on its name (e.g. prefer python-xml instead of python2.6-xml).

imported_>bruno_araujo: /* Introduction */

2009-06-19T13:32:05Z

Introduction

← Older revision		Revision as of 13:32, 19 June 2009
Line 19:		Line 19:
	<b>FINISH ME</b>		<b>FINISH ME</b>

	- Any paths that have "python2.5" or "site-packages" will have to be changed to "python2.6" and "dist-packages", as these are the ones used on Python 2.6~~. An alternative is to make these paths more generic~~.		* Any paths that, for some reason, must have hardcoded "python2.5" or "site-packages" will have to be changed to "python2.6" and "dist-packages", as these are the ones used on Python 2.6.
	- If you use distutils for building your package, you must pass the --install-layout=deb flag for "setup.py install" in order to install to the proper locations.		* If you use distutils for building your package, you must pass the --install-layout=deb flag for "setup.py install" command inside debian/rules in order to install the files to the proper locations. If you're using CDBS for this task, use the variable DEB_PYTHON_INSTALL_ARGS_ALL for passing the flag, e.g.:
	- If your application uses "python2.5" as one of its dependencies ~~on the~~ Depends field, you ~~must change it for "~~python2.~~6" or, preferably,~~ python (>= 2.5). Also, this would be a good time for your package to use dependencies that follow the new Debian Python Policy, if that's the case - the Policy states that Python packages must not have a fixed version number on its name (e.g. prefer python-xml instead of python2.6-xml).
			::DEB_PYTHON_INSTALL_ARGS_ALL = --no-compile -O0 --install-layout=deb

			* If your application uses any python2.5 package as one of its dependencies in any Depends field, you should drop the version number and add the version as a requirement - as a example, python2.5 can be changed to python (>= 2.5) without problems. If this is not possible/desired, just change the dependencies to python2.6.
			* Also, this would be a good time for your package to use dependencies that follow the new Debian Python Policy, if that's the case - the Policy states that Python packages must not have a fixed version number on its name (e.g. prefer python-xml instead of python2.6-xml).

imported_>lizardo at 20:49, 18 June 2009

2009-06-18T20:49:07Z

← Older revision		Revision as of 20:49, 18 June 2009
Line 2:		Line 2:

	<b style="color: red">Important: this document is still a draft. There are currently no planned dates for migration to 2.6, but it will be informed in advance on the maemo-developers and pymaemo-developers mailing lists, so that developers have some time to fix their packages.</b>		<b style="color: red">Important: this document is still a draft. There are currently no planned dates for migration to 2.6, but it will be informed in advance on the maemo-developers and pymaemo-developers mailing lists, so that developers have some time to fix their packages.</b>

			This documents contains some general guidelines about how to port your Python application currently being used with Python 2.5 for working without problems with Python 2.6.

			=== Introduction ===

			Currently, Maemo 4.x (Diablo) has Python 2.5. Maemo 5 Beta (Fremantle) also has 2.5, but we are evaluating upgrading Fremantle to 2.6, so that developers can use the latest features, while keeping compatibility with Python 2.5. See the [http://docs.python.org/whatsnew/2.6.html What’s New in Python 2.6] page for details.

			This also means that we have no plans to migrate to Python 3.x in Fremantle. Using Python 2.6 is the best option because developers can use most 3.x features without breaking compatibility with Python 2.5.

			One question might arise: why not have both 2.6 and 3.x, or even 2.5, 2.6 and 3.x? We have thought about this, the problem is, in the current mechanism used in Debian and Ubuntu (that we also use), the packages that install Python extensions need to be compiled for all supported versions, and all these versions are installed <b>in a single package</b>. This means that some packages will simply double or triple their size even if only one version is installed.

			Besides, if we have two or three versions available in the repository, there is a possibility that some packages depend on e.g. 2.5 while others depend 3.x. So the user would need to have <b>both</b> versions installed in some cases.

			For small devices as the Internet Tablets, saving space is also a high priority, so we decided to support a single version during the life cycle of the distribution.

			<b>FINISH ME</b>

			- Any paths that have "python2.5" or "site-packages" will have to be changed to "python2.6" and "dist-packages", as these are the ones used on Python 2.6. An alternative is to make these paths more generic.
			- If you use distutils for building your package, you must pass the --install-layout=deb flag for "setup.py install" in order to install to the proper locations.
			- If your application uses "python2.5" as one of its dependencies on the Depends field, you must change it for "python2.6" or, preferably, python (>= 2.5). Also, this would be a good time for your package to use dependencies that follow the new Debian Python Policy, if that's the case - the Policy states that Python packages must not have a fixed version number on its name (e.g. prefer python-xml instead of python2.6-xml).

imported_>lizardo: New page: == Python 2.6 Porting Guide == Important: this document is still a draft. There are currently no planned dates for migration to 2.6, but it will be informed in advan...

2009-06-18T20:29:19Z

New page: == Python 2.6 Porting Guide == <b style="color: red">Important: this document is still a draft. There are currently no planned dates for migration to 2.6, but it will be informed in advan...

New page
== Python 2.6 Porting Guide ==

<b style="color: red">Important: this document is still a draft. There are currently no planned dates for migration to 2.6, but it will be informed in advance on the maemo-developers and pymaemo-developers mailing lists, so that developers have some time to fix their packages.</b>