Greetings, following is the weekly update for gpypi2 project. It's main purpose is to generate ebuilds from Python Package Index. Quick links to project info:

• Repository, issue tracker
• Hudson CI instance
• Sphinx documentation generated by hudson on each commit

Very successful 2 weeks. Two days of vacations and nice shiney configuration utility together with questionnaire.

Currently, gpypi2 code only takes configuration from command line.
I'd like to extend that to config file (.ini), get data directly from setup.py
and interactive questionaire. In order for that to function properly,
configuration needs to be done in right sequence.

Following week I will write down the design and implement initial working prototype.

When I will get bored or stuck with task #1, I'll start working on command that will
generate ebuilds from all packages in pypi to an overlay.

Code currently has about `60 TODOs <http://hudson.fubar.si/job/g-pypi2/portage=portage2.1,python=2.6/58/tasksResult/?>`_ that need to be address for a better codebase.

I'll peek into distutils heart and implement most basic bdist command to output an ebuild.
I will basically the same stuff we currently do,
except it will parse data from setup.py itself and not through pypi.

Thanks to http://xercestech.com/app-engine-server-monitor.geek

Go to https://appengine.google.com/ and register application with {app-name}

wget http://googleappengine.googlecode.com/files/google_appengine_1.3.5.zip
unzip google_appengine_1.3.5.zip
cd google_appengine
git clone git://github.com/mrsteveman1/aeservmon.git {app-name}
vim {app-name}/app.yaml # set application
python appcfg.py update {app-name}

Result: http://web-monitoring.appspot.com/

Packaging love-hate world in Python is with every Python developer. Each time you need something from setuptools/distribute/distutils you actually find something new, useful. Can not deny that. There are quite some people working hard on distutils2 to remove the "miserable" word from packaging. I'm really hoping that lack of communication with Python developers and Linux distribution will be fixed when people will not only care, but also give constructive thoughts how distutils could be improved (and thus make life easier even to Linux distributions).

Enough of non-sense philosophy. Recently I found about "Feature" class in setuptools/distribute. Let's see what setuptools has to say about "features" keyword passed to the famous setup function:

'features' -- a dictionary mapping option names to 'setuptools.Feature'
        objects.  Features are a portion of the distribution that can be
        included or excluded based on user options, inter-feature dependencies,
        and availability on the current system.  Excluded features are omitted
        from all setup commands, including source and binary distributions, so
        you can create multiple distributions from the same source tree.
        Feature names should be valid Python identifiers, except that they may
        contain the '-' (minus) sign.  Features can be included or excluded
        via the command line options '--with-X' and '--without-X', where 'X' is
        the name of the feature.  Whether a feature is included by default, and
        whether you are allowed to control this from the command line, is
        determined by the Feature object.  See the 'Feature' class for more
        information.

Basically, you can do optional handling what should be installed when user executes "python setup.py --with-something install"

According to nullege, documentation for Feature class is the following:

A subset of the distribution that can be excluded if unneeded/wanted

Features are created using these keyword arguments:

  'description' -- a short, human readable description of the feature, to
     be used in error messages, and option help messages.

  'standard' -- if true, the feature is included by default if it is
     available on the current system.  Otherwise, the feature is only
     included if requested via a command line '--with-X' option, or if
     another included feature requires it.  The default setting is 'False'.

  'available' -- if true, the feature is available for installation on the
     current system.  The default setting is 'True'.

  'optional' -- if true, the feature's inclusion can be controlled from the
     command line, using the '--with-X' or '--without-X' options.  If
     false, the feature's inclusion status is determined automatically,
     based on 'availabile', 'standard', and whether any other feature
     requires it.  The default setting is 'True'.

  'require_features' -- a string or sequence of strings naming features
     that should also be included if this feature is included.  Defaults to
     empty list.  May also contain 'Require' objects that should be
     added/removed from the distribution.

  'remove' -- a string or list of strings naming packages to be removed
     from the distribution if this feature is *not* included.  If the
     feature *is* included, this argument is ignored.  This argument exists
     to support removing features that "crosscut" a distribution, such as
     defining a 'tests' feature that removes all the 'tests' subpackages
     provided by other features.  The default for this argument is an empty
     list.  (Note: the named package(s) or modules must exist in the base
     distribution when the 'setup()' function is initially called.)

  other keywords -- any other keyword arguments are saved, and passed to
     the distribution's 'include()' and 'exclude()' methods when the
     feature is included or excluded, respectively.  So, for example, you
     could pass 'packages=["a","b"]' to cause packages 'a' and 'b' to be
     added or removed from the distribution as appropriate.

A feature must include at least one 'requires', 'remove', or other
keyword argument.  Otherwise, it can't affect the distribution in any way.
Note also that you can subclass 'Feature' to create your own specialized
feature types that modify the distribution in other ways when included or
excluded.  See the docstrings for the various methods here for more detail.
Aside from the methods, the only feature attributes that distributions look
at are 'description' and 'optional'.

A very good example that abuses "features" is jinja2's setup.py.

Greetings, following is the weekly update for gpypi2 project. It's main purpose is to generate ebuilds from Python Package Index. Quick links to project info:

• Repository, issue tracker
• Hudson CI instance
• Sphinx documentation generated by hudson on each commit
• wiki/user stories for scrum development

Last two weeks were crazy at university. Now I shall have time to work on gpypi2 full-time until the end of program.

Install gpypi2

$ sudo pip install http://bitbucket.org/iElectric/g-pypi2/get/tip.zip

or

$ sudo easy_install http://bitbucket.org/iElectric/g-pypi2/get/tip.zip

Create an ebuild

$ sudo gpypi2 create flask

 * Generating ebuild: Flask 0.4
 * Your ebuild is here: /usr/local/portage/dev-python/flask/flask-0.4.ebuild
 * Dependency needed: Werkzeug
 * Dependency needed: Jinja2
 * Generating ebuild: Werkzeug 0.6.2
 * Your ebuild is here: /usr/local/portage/dev-python/werkzeug/werkzeug-0.6.2.ebuild
 * Generating ebuild: Jinja2 2.5
 * Your ebuild is here: /usr/local/portage/dev-python/jinja2/jinja2-2.5.ebuild
 * Dependency needed: Babel
 * Generating ebuild: Babel 0.9.5
 * Your ebuild is here: /usr/local/portage/dev-python/babel/babel-0.9.5.ebuild

NOTE: ebuilds will probably not function yet, features are yet to be completed/added. Report bugs to `issue tracker <http://bitbucket.org/iElectric/g-pypi2/issues?status=new&status=open>`_.

gpypi2.enamer.SrcUriNamer is awaiting for quite 2 weeks now
to be finally used.

It's basically factory that generates SRC_URI and HOMEPAGE
according to mirror provider.
A lot of additional refactoring will be needed to Enamer to
use this utility instead of current guessing/parsing.

Lot of bugs are going to pop up; fix bugs, write tests and
add documentation.

I'm still not satisfied with test coverage.
I'll try to increase it a bit more.
It's 10 days week of exams on my university, soon I will be able to put
in more effort in implementing features.

Currently, gpypi2 code only takes configuration from command line.
I'd like to extend that to config file (.ini), get data directly from setup.py
and interactive questionaire. In order for that to function properly,
configuration needs to be done in right sequence.

Following week I will write down the design and implement initial working prototype.

When I will get bored or stuck with task #1, I'll start working on command that will
generate ebuilds from all packages in pypi to an overlay.

Greetings, following is the weekly update for gpypi2 project. It's main purpose is to generate ebuilds from Python Package Index. Quick links to project info:

• Repository, issue tracker
• Hudson CI instance
• Sphinx documentation generated by hudson on each commit
• wiki/user stories for scrum development

I'm more than happy to announce first pre-alpha prototype. Intended goal is to make people start using the tool and reporting back their critics.

Install gpypi2

$ sudo pip install http://bitbucket.org/iElectric/g-pypi2/get/tip.zip

or

$ sudo easy_install http://bitbucket.org/iElectric/g-pypi2/get/tip.zip

Create an ebuild

$ sudo gpypi2 create flask

 * Generating ebuild: Flask 0.4
 * Your ebuild is here: /usr/local/portage/dev-python/flask/flask-0.4.ebuild
 * Dependency needed: Werkzeug
 * Dependency needed: Jinja2
 * Generating ebuild: Werkzeug 0.6.2
 * Your ebuild is here: /usr/local/portage/dev-python/werkzeug/werkzeug-0.6.2.ebuild
 * Generating ebuild: Jinja2 2.5
 * Your ebuild is here: /usr/local/portage/dev-python/jinja2/jinja2-2.5.ebuild
 * Dependency needed: Babel
 * Generating ebuild: Babel 0.9.5
 * Your ebuild is here: /usr/local/portage/dev-python/babel/babel-0.9.5.ebuild

NOTE: ebuilds will probably not function yet, features are yet to be completed/added. Report bugs to `issue tracker <http://bitbucket.org/iElectric/g-pypi2/issues?status=new&status=open>`_.

Put enough together to assemble ebuilds from command line. I think
many issues may pop up, and lots of bugs shall be fixed. I'm currently
mostly doing stuff from my head, with not much practise whatsoever.

Mostly, we should get a result of better test coverage (currrently about
50%).

The only component left untouched is the configuration. I would like to
touch this topic after all my exams are over, leaving me time and
productivity.

Title says it all. Also handling of multiple version operators should be
added.

Example: foobar>=0.5&& foobar<0.6

should resolve in <0.6 blocker and >=0.5 requirement.

gpypi2.enamer.SrcUriNamer is awaiting for quite 2 weeks now
to be finally used.

It's basically factory that generates SRC_URI and HOMEPAGE
according to mirror provider.
A lot of additional refactoring will be needed to Enamer to
use this utility instead of current guessing/parsing.

Lot of bugs are going to pop up; fix bugs, write tests and
add documentation.

I'm still not satisfied with test coverage.
I'll try to increase it a bit more.
It's 10 days week of exams on my university, soon I will be able to put
in more effort in implementing features.