177 lines
5.5 KiB
Plaintext
177 lines
5.5 KiB
Plaintext
TODO
|
|
====
|
|
* Automatically build and publish binary wheels on pypi
|
|
- for py: 36,37,38,39,310
|
|
- for linux x86 and rpi
|
|
- see https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/
|
|
- see https://github.com/pypa/manylinux
|
|
- also include efl itsef in the wheels? PySide is doing this
|
|
|
|
* Drop python 2 compatibility
|
|
- Switch to cython3
|
|
- remove all the workarounds for py2 (see strings and enums)
|
|
|
|
* Improved editors support, at least on VSCode and PyCharm
|
|
|
|
* Try to implement better the elementary module, removing
|
|
the __init__ module hack (that create problems in the docs)
|
|
|
|
* Make the examples a first citizen!
|
|
- install them with python efl
|
|
- make them easily runnable
|
|
- show them in the docs
|
|
- show the code inside the examples themself?
|
|
- make the code editable on the fly?
|
|
|
|
|
|
Style
|
|
=====
|
|
|
|
* For indentation, use *four space characters* per level of indentation. Keep
|
|
lines under the 80 chars limit (only exception are the functions definition)
|
|
|
|
* When comparing C pointers with NULL, use == and != instead of the python
|
|
operator "is". This makes a visual distinction between python and C code.
|
|
|
|
* For long lines that do not fit in the 80 cols please use only the first
|
|
raccomandation from PEP-8 (Aligned with opening delimiter). Example:
|
|
Yes:
|
|
foo = long_function_name(var_one, var_two,
|
|
var_three, var_four)
|
|
No:
|
|
foo = long_function_name(
|
|
var_one, var_two,
|
|
var_three, var_four)
|
|
|
|
This to keep new code consistent with the rest of the bindings and to
|
|
try to match the style of the C efl code style as much as possible.
|
|
...also because I found it more readable and I like it more :P -davemds-
|
|
|
|
|
|
Documentation cheatsheet
|
|
========================
|
|
|
|
* Links:
|
|
|
|
:class:`List` (for classes)
|
|
:func:`elm_list_go` (for functions)
|
|
:attr:`homogeneous` (for properties)
|
|
:ref:`Elm_List_Mode` (for enums)
|
|
:data:`ELM_LIST_LIMIT` (for enum values)
|
|
|
|
:func:`efl.evas.Object.delete` (for items not in current scope)
|
|
:func:`~efl.evas.Object.delete` (will show it short, just "delete")
|
|
|
|
* Formatting:
|
|
|
|
``ELM_LIST_SCROLL`` (for enum values, bools and None)
|
|
|
|
|
|
* Versions:
|
|
|
|
.. versionadded:: 1.15
|
|
|
|
.. versionchanged:: 1.15
|
|
Description of the change.
|
|
|
|
.. deprecated:: 1.15
|
|
Use the blah, blah way instead.
|
|
|
|
* Notes:
|
|
|
|
.. seealso:: :py:attr:`mode`
|
|
|
|
.. note:: Some text to be noted, blah, blah, blah,
|
|
some more information for this note, etc.
|
|
|
|
.. warning:: Same as note, but the box will be red
|
|
some more information for this warning, etc.
|
|
|
|
|
|
Design patterns
|
|
===============
|
|
|
|
* From "The Zen of Python":
|
|
|
|
Beautiful is better than ugly.
|
|
Explicit is better than implicit.
|
|
Simple is better than complex.
|
|
Complex is better than complicated.
|
|
Flat is better than nested.
|
|
Sparse is better than dense.
|
|
Readability counts.
|
|
Special cases aren't special enough to break the rules.
|
|
Although practicality beats purity.
|
|
Errors should never pass silently.
|
|
Unless explicitly silenced.
|
|
In the face of ambiguity, refuse the temptation to guess.
|
|
There should be one-- and preferably only one --obvious way to do it.
|
|
Although that way may not be obvious at first unless you're Dutch.
|
|
Now is better than never.
|
|
Although never is often better than *right* now.
|
|
If the implementation is hard to explain, it's a bad idea.
|
|
If the implementation is easy to explain, it may be a good idea.
|
|
Namespaces are one honking great idea -- let's do more of those!
|
|
|
|
|
|
Tips
|
|
====
|
|
|
|
* cython does automatic dict <-> struct conversion with basic struct members
|
|
|
|
|
|
Release process instructions
|
|
============================
|
|
|
|
* use "api_coverage.py --python elementary" to see the missing bindings
|
|
|
|
* Version:
|
|
- change versions in efl/__init__.py (ex: 1.9.0)
|
|
- update EFL_MIN_VER in setup.py (if needed)
|
|
|
|
* Update the ChangeLog file:
|
|
- setup.py build_doc -b changes ...and manually merge from the html file
|
|
|
|
* Generate the source (tar) and binary (wheel) distributions:
|
|
- make maintainer-clean (just to be sure nothing is cached)
|
|
- make dist
|
|
|
|
* Test the generated tarball and wheel:
|
|
- the targz must work by extracting and running: python setup.py install [--user]
|
|
- the targz must be installable using: pip install python-efl-1.9.0.tar.gz
|
|
- the wheel must be installable using: pip install python_efl-1.9.0-xxxx.whl
|
|
|
|
* Publish the 2 tar archive on e.org:
|
|
- scp tarballs & md5sums to:
|
|
download.enlightenment.org:/srv/web/download.enlightenment.org/rel/bindings/python/
|
|
- update download link on the wiki (www.enlightenment.org/download)
|
|
|
|
* Publish the .tar.gz archive on pypi:
|
|
- twine upload python-efl-1.9.0.tar.gz [--repository testpypy]
|
|
- TODO: also upload binary wheels for linux py36,37,38,39,310 (see manylinux on pypa)
|
|
|
|
* Documentation:
|
|
- make doc (check that inheritance graphs are there)
|
|
- scp the generated html documentation to:
|
|
download.enlightenment.org:/srv/web/docs.enlightenment.org/python-efl/1.9.0/
|
|
- update the 'current' link on the server (ssh)
|
|
|
|
* Create and push the tag for the release
|
|
- git tag -a v1.9.0 && git push origin v1.9.0
|
|
|
|
* Create and push the branch for stable backporting
|
|
git branch python-efl-1.9 && git push origin python-efl-1.9
|
|
|
|
* Announce the release to release@lists.enlightenment.org and
|
|
enlightenment-release@lists.sourceforge.net
|
|
|
|
* Change versions again in efl/__init__.py (ex: 1.9.99)
|
|
|
|
for more info:
|
|
--------------
|
|
* packaging.python.org
|
|
* phab.enlightenment.org/w/release_procedure/
|
|
* phab.enlightenment.org/w/hosting/ssh/
|
|
|
|
|