Outils personnels
Vous êtes ici : Accueil Topics python
HADOPI - Le Net en France : black-out

python

07/03/2010

minitage.recipe.egg, another fancy error log about distributions requirers

by kiorky — last modified 07/03/2010 20:41
Classé sous :

When having trouble while installing an egg during the installation phase(easy_install time)

Now the recipe can display some information about which wanted this distribution.

This is even more useful that it support up to 6 dependencies levels from direct to parents !

Here is an example:

 

Processing ssl-for-setuptools-1.10.tar.gz
Unpacking ssl-for-setuptools-1.10 to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10
Unpacking ssl-for-setuptools-1.10/PKG-INFO to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/PKG-INFO
Unpacking ssl-for-setuptools-1.10/setup.py to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/setup.py
Unpacking ssl-for-setuptools-1.10/ssl to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/ssl
Unpacking ssl-for-setuptools-1.10/ssl/2.3.6 to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/ssl/2.3.6
Unpacking ssl-for-setuptools-1.10/ssl/2.3.6/socketmodule.h to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/ssl/2.3.6/socketmodule.h
Unpacking ssl-for-setuptools-1.10/ssl/2.5.1 to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/ssl/2.5.1
Unpacking ssl-for-setuptools-1.10/ssl/2.5.1/socketmodule.h to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/ssl/2.5.1/socketmodule.h
Unpacking ssl-for-setuptools-1.10/ssl/__init__.py to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/ssl/__init__.py
Unpacking ssl-for-setuptools-1.10/ssl/_ssl2.c to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/ssl/_ssl2.c
Unpacking ssl-for-setuptools-1.10/test to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/test
Unpacking ssl-for-setuptools-1.10/test/badcert.pem to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/test/badcert.pem
Unpacking ssl-for-setuptools-1.10/test/badkey.pem to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/test/badkey.pem
Unpacking ssl-for-setuptools-1.10/test/https_svn_python_org_root.pem to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/test/https_svn_python_org_root.pem
Unpacking ssl-for-setuptools-1.10/test/keycert.pem to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/test/keycert.pem
Unpacking ssl-for-setuptools-1.10/test/nullcert.pem to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/test/nullcert.pem
Unpacking ssl-for-setuptools-1.10/test/test_ssl.py to /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/test/test_ssl.py
Running ssl-for-setuptools-1.10/setup.py bdist_egg --dist-dir /tmp/easy_install-Svj7d6/ssl-for-setuptools-1.10/egg-dist-tmp-NfSQin
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 1714, in main
    with_ei_usage(lambda:
  File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 1695, in with_ei_usage
    return f()
  File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 1718, in <lambda>
    distclass=DistributionWithoutHelpCommands, **kw
  File "/usr/lib/python2.6/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/lib/python2.6/distutils/dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
    cmd_obj.run()
  File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 236, in run
    self.easy_install(spec, not self.no_deps)
  File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 452, in easy_install
    return self.install_item(None, spec, tmpdir, deps, True)
  File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 501, in install_item
    dists = self.install_eggs(spec, download, tmpdir)
  File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 680, in install_eggs
    return self.build_and_install(setup_script, setup_base)
  File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 957, in build_and_install
    self.run_setup(setup_script, setup_base, args)
  File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/command/easy_install.py", line 946, in run_setup
    run_setup(setup_script, args)
  File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/sandbox.py", line 29, in run_setup
    lambda: execfile(
  File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/sandbox.py", line 70, in run
    return func()
  File "/home/kiorky/minitage/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg/setuptools/sandbox.py", line 31, in <lambda>
    {'__file__':setup_script, '__name__':'__main__'}
  File "setup.py", line 11, in <module>
    def read(rnames):
ValueError: This extension should not be used with Python 2.6 or later (already built in), and has not been tested with Python 2.3.4 or earlier.
    - Failed specs: ssl-for-setuptools==1.10
    - required by:
        - [Requirement.parse('zc.ssl==1.1')]
    - required by:
        - [Requirement.parse('zc.authorizedotnet==1.3')]
    - required by:
        - [Requirement.parse('easyshop.core==0.1a1')]
    - Failed specs: ssl-for-setuptools==1.10
    - required by:
        - [Requirement.parse('zc.ssl==1.1')]
    - required by:
        - [Requirement.parse('zc.authorizedotnet==1.3')]
    - required by:
        - [Requirement.parse('easyshop.core==0.1a1')]
While:
  Installing zopepy.

 

We see at first shot that easyshop give us trouble ! Without, its hard to know which distribution want ssl-for-setuptools :)

28/02/2010

minitage, python and UCS

by kiorky — last modified 28/02/2010 22:39
Classé sous :

While upgrading my gentoo based laptop after 8monthes of lazy abandonness in profit of exiting projects, i saw that the gentoo's python was forced to use UCS==4.

What an heck while dealing with the 'minitage env' file which mix the system and project environment resulting in a mixin of the system and project python.

Normally, there are no problem, unless your pythons come with different UCS flavors.

Cool thing is that those errors are not silent, and you see them if you are hitted by this flaw :

    ImportError: /bar.egg/module/_foo.so: undefined symbol: PyUnicodeUCS4_DecodeUTF8
or  
    ImportError: /bar.egg/module/_foo.so: undefined symbol: PyUnicodeUCS2_DecodeUTF8

 

Making some searches showed me that upstream as in python-dev supports only UCS2 by default (issue discussed on their mailing around 2008) but all distros i am aware of package their distros with UCS==4.

For now, I prefered to stick with upstream (UCS==2), but i think that for the user experience, UCS==4 will be better.

Sad thing is that for existing minitage installations if you want to rebuild your python, do also that:

rm -rf minitage/eggs/cache/*-Major.minor*egg
rm -rf minitage/eggs/*/.installed.cfg

To let minitage rebuild any stuff using UCS2.

 

See http://en.wikipedia.org/wiki/Universal_Character_Set for reference on UCS.

26/02/2010

Python and oldies or ValueError: year=1876 is before 1900; the datetime strftime() methods require year >= 1900

by kiorky — last modified 26/02/2010 17:40
Classé sous :

Calling strftime on a date/datetime instance on py24/py26 will raise a value error like this:

>>> from datetime import date
>>> date(1800,1,1).strftime('%d%m%Y')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: year=1800 is before 1900; the datetime strftime() methods require year >= 1900

Quite annoying heh ?

There is a bug related on the python bugtracker here : http://bugs.python.org/issue1777412

 

The work here was to integrate the working patch in the bugreport to py24 and py26 python packages which are in minitage.

So now, with minitage's pythons, you can work with very old dates by default !!!

Just issue:

virtualenv --no-site-packages --distribute minitage
source minitage/bin/activate
minimerge -s
minimerge -v python-2.6 (or 2.4)

And you can use the following interpreter which support those old ages:

minitage/python-2.6/parts/part/bin/python

 

And of course the related patch does not break anything:

$ svn info
URL : http://svn.python.org/projects/python/branches/release24-maint
Révision : 75208
$../parts/part/bin/python Lib/test/test_datetime.py
...
----------------------------------------------------------------------
Ran 230 tests in 0.858s
OK


$ pwd
/home/kiorky/minitage/dependencies/python-2.6/Python-2.6.4
$../parts/part/bin/python Lib/test/test_datetime.py
...
----------------------------------------------------------------------
Ran 245 tests in 0.791s
OK

 

24/06/2009

make mapscript easy_installable

by kiorky — last modified 24/06/2009 22:50

As part of a new project deployment plan, we needed to deploy mapscript.

Python-MapScript are the python bindings to the underlying mapserver library.

Where the pain begins is that there is no egg available for it, but an old fashioned distutils distribution;.

 

My bits there were to make some quickly egg compatible on most unixes. My will is to make it nicer and be integrated on the mapserver trunk code.

You can find the code there : http://git.minitage.org/git/others/mapscript/

 

And play with the egg:

easy_install mapscript 

You must know that mapserver-config must be available in your $PATH.