| 1 |
Greetings, following is the weekly update for g-pypi project. |
| 2 |
It's main purpose is to generate ebuilds from PyPi. |
| 3 |
|
| 4 |
Quick links to project info: |
| 5 |
* http://bitbucket.org/iElectric/g-pypi2- Repository, issue tracker |
| 6 |
* http://hudson.fubar.si/job/g-pypi2/ - Hudson CI instance |
| 7 |
* http://docs.fubar.si/gpypi2/ - Sphinx documentation generated by |
| 8 |
hudson on each commit |
| 9 |
* http://neurogeek.ath.cx/g-pypi - wiki/user stories for scrum |
| 10 |
development |
| 11 |
|
| 12 |
|
| 13 |
Previous week (31-07 June) |
| 14 |
========================= |
| 15 |
|
| 16 |
Crazy week is behind me -- don't even ask:) |
| 17 |
|
| 18 |
--------------------------------------------------------------------- |
| 19 |
Task: write class that tries to get SRC_URI (currently implementation |
| 20 |
will query pypi and sourceforge by issuing HEAD HTTP request) |
| 21 |
--------------------------------------------------------------------- |
| 22 |
|
| 23 |
Implementation is more or less finished, tests are yet to be written. |
| 24 |
I'm not really sure I'm satisfied with current implementation as it |
| 25 |
uses metaclasses to achieve pluggability. |
| 26 |
|
| 27 |
Solution for guessing stuff directly from download url (like pn and pv |
| 28 |
is yet to be rewritten). I wonder if that's even sane. |
| 29 |
|
| 30 |
http://bitbucket.org/iElectric/g-pypi2/src/tip/gpypi2/enamer.py#cl-688 |
| 31 |
|
| 32 |
----------------------------------------------------------------- |
| 33 |
Task: generate basic structure of templates (we are using jinja2) |
| 34 |
----------------------------------------------------------------- |
| 35 |
|
| 36 |
Done, we have ebuild.tmpl which inherits from common.tmpl (provides |
| 37 |
some basic blocks helpers). |
| 38 |
|
| 39 |
I have migrated all template stuff into template, reducing ebuild.py |
| 40 |
for quite some lines. |
| 41 |
|
| 42 |
http://bitbucket.org/iElectric/g-pypi2/src/96c9122ca0d3/gpypi2/templates/ |
| 43 |
|
| 44 |
|
| 45 |
--------------------------------------------------------------------- |
| 46 |
Task: refactor and get familiar with ebuild.py, also write tests and |
| 47 |
docs |
| 48 |
--------------------------------------------------------------------- |
| 49 |
|
| 50 |
I have cleaned the Ebuild class, but still a lot of work can be done |
| 51 |
to make it easier to follow the flow. |
| 52 |
|
| 53 |
http://bitbucket.org/iElectric/g-pypi2/src/96c9122ca0d3/gpypi2/ebuild.py |
| 54 |
|
| 55 |
|
| 56 |
Upcoming week (01-06 June) |
| 57 |
========================== |
| 58 |
|
| 59 |
--------------------------------------------------------------------- |
| 60 |
Task: get working version of ebuild.py |
| 61 |
--------------------------------------------------------------------- |
| 62 |
|
| 63 |
This will be main goal of the week. Refactor ebuild.py and make it work |
| 64 |
with enamer.py and portage_utils.py |
| 65 |
|
| 66 |
Following is incomplete list of taks on ebuild.py: |
| 67 |
|
| 68 |
* get rid of last snippets for generating template with python code |
| 69 |
* port some functions (like format_depend) to jinja environment filters |
| 70 |
* get rid of all non-sense if/else statements (I will probably make |
| 71 |
ebuild inherit from dict) |
| 72 |
* add support to detect Sphinx documentation |
| 73 |
* do not regex parse setup.py files but rather mock the setup object |
| 74 |
and collect metadata (still not sure if that will cover most of cases) |
| 75 |
* repair flow of the code to be easier to understand and document it |
| 76 |
|
| 77 |
|
| 78 |
--------------------------------------------------------------------- |
| 79 |
Idea: configuration |
| 80 |
--------------------------------------------------------------------- |
| 81 |
|
| 82 |
In one to two weeks I will have code ready to produce first ebuilds. |
| 83 |
gpypi will query the PyPi and echo an ebuild. But many times, not all |
| 84 |
information is correct/given on PyPi. Thus, ways to update information |
| 85 |
should be available. |
| 86 |
|
| 87 |
Idea is to provide different configuration providers, here is the list |
| 88 |
I had in mind: |
| 89 |
|
| 90 |
* pypi |
| 91 |
* setup.py |
| 92 |
* .ini |
| 93 |
* interactive console session |
| 94 |
|
| 95 |
Of course, one should be able to add aditional one. Here is how one |
| 96 |
would configure the sequence of configurations: |
| 97 |
|
| 98 |
[metadata-providers] |
| 99 |
provider1 = some.package:MetadataProvider |
| 100 |
list = pypi ini provider1 interactive |
| 101 |
|
| 102 |
Interactive console session would work similar to "sphinx-build" or "paster create" behaviour. |
| 103 |
At the end, warning is printed for each mission ebuild information. |
| 104 |
|
| 105 |
That's all from me folks, cheers Domen |
Archives