natty support

[Will Kahn-Greene]

Running python setup.py develop on Ubuntu Natty doesn't work. PIL
doesn't get compiled with jpeg or png support. This happens with
both the virtualenv and buildout instructions.

Doing a Google search leads to the following interesting urls:


-  `http://ubuntuforums.org/showthread.php?t=1751455 <http://ubuntuforums.org/showthread.php?t=1751455>`_
-  `http://www.isnull.com.ar/2011/05/solved-python-pil-ioerror-decoder-jpeg.html <http://www.isnull.com.ar/2011/05/solved-python-pil-ioerror-decoder-jpeg.html>`_

This is a big deal because it means people using Ubuntu Natty can't
run GNU MediaGoblin.

[Will Kahn-Greene]

There are a few issues here.


1. if the user uses buildout, then celeryd picks up the system
   python-datetime module, but needs a more recent one.

2. if the user uses virtualenv with --no-site-packages, then pil
   gets compiled without libjpeg/libpng support and is thus
   effectively useless.

3. if the user uses virtualenv with site packages, then everything
   works fine, but allowing for site packages potentially creates
   other problems.

[Sebastian Spaeth]

03:35 ok. so, options are probably something like this:
03:35 1. virtualenv with site packages and tell people to pip
install
datetime over the existing system one. (yuck)
03:36 2. roll our own pypi with all the stuff. (total yuck and a
lot
of work)
03:36 3. not use pil and instead use mogrify or something.
03:36 4. tell people not to use natty.
03:36 mmm... i can't think of any others.

One more comment. You forgot about `#5 </issues/5>`_:

Modify the sys.path0 serach path so that it finds a local dateutil
before searching the system one. In buildout that was simply
possible by editing the few lines in bin/parser. I know that one is
being automatically created by buildout, but looking at the
buildout stuff, it does check e.g. for existing PYTHONPATH etc. So,
I am not sure it is not possible to convinve buildout to put this
dist package before the system one.

[Sebastian Spaeth]

BTW, I have been able to get it work on natty with the following
buildout.cfg

::

    [buildout]
    develop = . 
    parts = mediagoblin make_user_dev_dirs
    
    [mediagoblin]
    recipe=zc.recipe.egg
    interpreter=python
    dependent-scripts = true
    eggs=
        python-dateutil>=1.5.0,<2.0.0
        mediagoblin
    entry-points = 
        nosetests=nose:run_exit
        paster=paste.script.command:run
    
    [make_user_dev_dirs]
    recipe = mediagoblin:make_user_dev_dirs
    path = user_dev

As a consequence, buildout created the followin sys.path0:

::

    sys.path[0:0] = [
        '/home/spaetz/src/mediagoblin/eggs/python_dateutil-1.5-py2.7.egg',
        '/home/spaetz/src/mediagoblin',
        ...

And the startup worked flawlessly even after re-"buildout"ing.

It might seem a bit ugly to put a dependency there (I don't know
buildout...), but it did work using buildout. Hope that helps
getting this running on natty with less effort.

[Sebastian Spaeth]

One more issue I had with "buildout" on natty:

14:14 BTW, current buildout did not like my system python-pymongo
and
failed with a mysterious "mongo master not found". When I
removed system python-pymongo it used the egg and all was fine.
So this might also be a candidate for sys.path0 fudging. I guess
the same way as the dateutil thing above in buildout.cfg should
work.

I have a running mediagoblin in natty now, using buildout. I can
submit things and see the images.

[Will Kahn-Greene]

Sebastian Spaeth wrote:

    03:35 ok. so, options are probably something like this:
    03:35 1. virtualenv with site packages and tell people to pip
    install
    datetime over the existing system one. (yuck)
    03:36 2. roll our own pypi with all the stuff. (total yuck and a
    lot
    of work)
    03:36 3. not use pil and instead use mogrify or something.
    03:36 4. tell people not to use natty.
    03:36 mmm... i can't think of any others.


I had purposefully not included these options because they're not
very useful. That wasn't an oversight.

    One more comment. You forgot about `#5 </issues/5>`_:

    Modify the sys.path0 serach path so that it finds a local dateutil
    before searching the system one. In buildout that was simply
    possible by editing the few lines in bin/parser. I know that one is
    being automatically created by buildout, but looking at the
    buildout stuff, it does check e.g. for existing PYTHONPATH etc. So,
    I am not sure it is not possible to convinve buildout to put this
    dist package before the system one.


I didn't forget about this--I didn't think it was worth talking
about. It requires the dev to change bin/parser every time they run
buildout and that sucks.

[Will Kahn-Greene]

Sebastian Spaeth wrote:

    BTW, I have been able to get it work on natty with the following
    buildout.cfg
    [...]

    As a consequence, buildout created the followin sys.path0:

    [...]

    And the startup worked flawlessly even after re-"buildout"ing.

    It might seem a bit ugly to put a dependency there (I don't know
    buildout...), but it did work using buildout. Hope that helps
    getting this running on natty with less effort.


Can you put this together in a patch and attach it?

[Sebastian Spaeth]

Patch commit is here:
`https://gitorious.org/mediagoblin/mediagoblin/merge\_requests/6 <https://gitorious.org/mediagoblin/mediagoblin/merge_requests/6>`_

[Sebastian Spaeth]

0001-Enforce-using-local-dateutil-with-buildout.patch

[Sebastian Spaeth]

willkg told me we don't use the gitorious merge request machinery,
so here is the patch

[Sebastian Spaeth]

0001-Enforce-using-local-dateutil-with-buildout.patch

[Sebastian Spaeth]

Identified another issue with system python-pymongo on Ubuntu
Natty, which would always cause
*AutoReconnect("could not find master/primary")* errors. Forcing
using a local one here too.

[Christopher Allan Webber]

Thanks for the patch, pushed. I wonder if it does fix everyone's
things? I'll assume it does for now.

If that's not true please let me know otherwise.

[Will Kahn-Greene]

The original url for this bug was ​http://bugs.foocorp.net/issues/308 .