HOWTO: Installing Pylons on Hardy
Joshua D. Drake
I recently had to do this for a customer. It wasn't as easy as it should
be, but it was hardly difficult. I have blogged it here if any are
interested:
http://www.commandprompt.com/blogs/joshua_drake/2009/02/configuring_pylons_on_ubuntu_hardy/
I do make some assumptions in the document but anyone reasonably
familiar with how to use a web browser and their own system
configuration shouldn't have any problems.
Comments welcome.
Sincerely,
Joshua D. Drake
--
PostgreSQL - XMPP: jdr...@jabber.postgresql.org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997
m h
>
> Hello,
>
> I recently had to do this for a customer. It wasn't as easy as it should
> be, but it was hardly difficult. I have blogged it here if any are
> interested:
>
> http://www.commandprompt.com/blogs/joshua_drake/2009/02/configuring_pylons_on_ubuntu_hardy/
>
> I do make some assumptions in the document but anyone reasonably
> familiar with how to use a web browser and their own system
> configuration shouldn't have any problems.
>
> Comments welcome.
Can't figure out how to comment on your blog....
It seems that installation/configuration of apache is what is
hard/painful. Installing pylons is pretty straightforward on
ubuntu/gentoo/macos....
-matt
Joshua D. Drake
> On Fri, Feb 6, 2009 at 5:29 PM, Joshua D. Drake <j...@commandprompt.com>
> wrote:
> >
> > Comments welcome.
>
> Can't figure out how to comment on your blog....
>
> It seems that installation/configuration of apache is what is
> hard/painful. Installing pylons is pretty straightforward on
> ubuntu/gentoo/macos....
>
know how to configure apache. I think that might be the stumbling block.
Joshua D. Drake
> -matt
Piotr Ozarowski
> sudo easy_install pylons
Please add "Please note that after this command, you cannot report bugs
against Python related Debian/Ubuntu packages and if you will want to
uninstall Pylons or some of your other applications will stop working,
reinstall your system (which normally, you should never do on Debian)"
NEVER INSTALL EGGS INTO GLOBAL SITE-PACKAGES!!!
hint: python-virtualenv
other hints:
since you're targeting Ubuntu: on Debian based systems to enable
Apache module (mod-wsgi is enabled by default after installing
libapache2-mod-wsgi, btw) all you need to do is: `a2enmod module` (f.e.
`a2enmod wsgi`)
Mike Orr
> [Joshua D. Drake]
>> sudo easy_install pylons
>
> Please add "Please note that after this command, you cannot report bugs
> against Python related Debian/Ubuntu packages and if you will want to
> uninstall Pylons or some of your other applications will stop working,
> reinstall your system (which normally, you should never do on Debian)"
>
> NEVER INSTALL EGGS INTO GLOBAL SITE-PACKAGES!!!
Both Debian and Ubuntu have /usr/local/lib/python2.X/site-packages,
which is expressly intended for locally-installed libraries like this.
Their Python interpreter has been modified to look both places. If
easy_install tries to put something into /usr/lib, a small change in
/usr/lib/python2.X/distutils/distutils.cfg or ~/.pydistutils.cfg will
correct it.)
> hint: python-virtualenv
Yes, this is a better way. Eventually you will have multiple
applications, and at some point you'll want to upgrade one while
another is still using older APIs. Even Setuptools has this problem
periodically, in that newer versions of Pylons or its dependencies
depend on a newer version of Setuptools than Debian provides. A
virtualenv will automatically install a private copy of Setuptools,
which can then be upgraded without affecting other production
applications.
I normally install Ubuntu packages only for things that have C
extensions that can be hard to compile. So python-mysqldb,
python-ldap, python-imaging, etc. These are pretty mature so the
default version is probably all you'll ever need. The same cannot be
said for Pylons, SQLAlchemy, Setuptools, etc.
--
Mike Orr <slugg...@gmail.com>
Piotr Ozarowski
> On Sat, Feb 7, 2009 at 8:02 AM, Piotr Ozarowski <oza...@gmail.com> wrote:
> > [Joshua D. Drake]
> >> sudo easy_install pylons
> >
> > Please add "Please note that after this command, you cannot report bugs
> > against Python related Debian/Ubuntu packages and if you will want to
> > uninstall Pylons or some of your other applications will stop working,
> > reinstall your system (which normally, you should never do on Debian)"
> >
> > NEVER INSTALL EGGS INTO GLOBAL SITE-PACKAGES!!!
>
> Both Debian and Ubuntu have /usr/local/lib/python2.X/site-packages,
> which is expressly intended for locally-installed libraries like this.
... by administrators who want to add some local modifications, not by
users who want to do some tests
let me cite FHS:
| The /usr/local hierarchy is for use by the system administrator when
| installing software locally. It needs to be safe from being overwritten
| when the system software is updated. It may be used for programs and
| data that are shareable amongst a group of hosts, but not found in /usr.
so, even if easy_install would install to /usr/local it still would be wrong.
> Their Python interpreter has been modified to look both places. If
> easy_install tries to put something into /usr/lib, a small change in
> /usr/lib/python2.X/distutils/distutils.cfg or ~/.pydistutils.cfg will
> correct it.)
note the "sudo" part in Joshua's command
> I normally install Ubuntu packages only for things that have C
> extensions that can be hard to compile. So python-mysqldb,
> python-ldap, python-imaging, etc. These are pretty mature so the
> default version is probably all you'll ever need. The same cannot be
> said for Pylons, SQLAlchemy, Setuptools, etc.
again, please don't install them into global site-packages (no matter if
you choose /usr or /usr/local). If you don't believe me it's a bad idea,
just list eggs you installed on your system and I'll give you names of
packages that you broke by using eggs.
Mike Orr
> [Mike Orr, 2009-02-07]
>> On Sat, Feb 7, 2009 at 8:02 AM, Piotr Ozarowski <oza...@gmail.com> wrote:
>> > [Joshua D. Drake]
>> >> sudo easy_install pylons
>> >
>> > Please add "Please note that after this command, you cannot report bugs
>> > against Python related Debian/Ubuntu packages and if you will want to
>> > uninstall Pylons or some of your other applications will stop working,
>> > reinstall your system (which normally, you should never do on Debian)"
>> >
>> > NEVER INSTALL EGGS INTO GLOBAL SITE-PACKAGES!!!
>>
>> Both Debian and Ubuntu have /usr/local/lib/python2.X/site-packages,
>> which is expressly intended for locally-installed libraries like this.
>
> ... by administrators who want to add some local modifications, not by
> users who want to do some tests
>
> let me cite FHS:
> | The /usr/local hierarchy is for use by the system administrator when
> | installing software locally. It needs to be safe from being overwritten
> | when the system software is updated. It may be used for programs and
> | data that are shareable amongst a group of hosts, but not found in /usr.
>
> so, even if easy_install would install to /usr/local it still would be wrong.
Ah, it's been a long time since I've seen a Linux system where the
user and system administrator weren't the same person.
--
Mike Orr <slugg...@gmail.com>
Piotr Ozarowski
> Ah, it's been a long time since I've seen a Linux system where the
> user and system administrator weren't the same person.
well, sometimes it needs some work to glue different Python modules and
applications together (Pylons devs/users should know this better than
others, no?) and guess who will be blamed if a random Python application
suddenly doesn't work anymore? Specially since using easy_install to
install modules system-wide is recommend everywhere (even by Python
programmers!).
FTR: I don't think easy_install is pure evil, it's simply not used sanely.
Joshua D. Drake
> Yes, this is a better way. Eventually you will have multiple
> applications, and at some point you'll want to upgrade one while
> another is still using older APIs. Even Setuptools has this problem
> periodically, in that newer versions of Pylons or its dependencies
> depend on a newer version of Setuptools than Debian provides. A
> virtualenv will automatically install a private copy of Setuptools,
> which can then be upgraded without affecting other production
> applications.
>
Depends on the environment. "I" will never have that problem. Others
might. Your suggestions are noted though.
Joshua D. Drake
This is interesting. To me the direction this thread took is in reverse.
Things should be installed globally. It is part of "production". You
define your deployment, your dependencies and that is what you get. That
way you don't have to much with silly things like virtualenv.
Once a machine of mine goes production, it never gets updated except for
security releases. If done properly they will not break apis and if they
do they better mention it in the release notes so we can test the app
before we do the upgrade.
If I need to have "another app" with a different version I will use a VM
or a new server.
Now, I have in the past installed things locally. In fact at one point I
used to install everything per user. It would be almost like they had a
FreeBSD jail where everything was at there disposal except system global
files but that was when I was working on apps where I had customers that
were unwilling to pay for environments of their own.
Joshau D. Drake
Piotr Ozarowski
>
> On Sat, 2009-02-07 at 23:18 +0100, Piotr Ozarowski wrote:
> > [Mike Orr, 2009-02-07]
> > > Ah, it's been a long time since I've seen a Linux system where the
> > > user and system administrator weren't the same person.
> >
> > well, sometimes it needs some work to glue different Python modules and
> > applications together (Pylons devs/users should know this better than
> > others, no?) and guess who will be blamed if a random Python application
> > suddenly doesn't work anymore? Specially since using easy_install to
> > install modules system-wide is recommend everywhere (even by Python
> > programmers!).
> >
> > FTR: I don't think easy_install is pure evil, it's simply not used sanely.
>
> This is interesting. To me the direction this thread took is in reverse.
> Things should be installed globally. It is part of "production". You
> define your deployment, your dependencies and that is what you get. That
> way you don't have to much with silly things like virtualenv.
installing globally is good (preferred, I'd even say, it's easier to fix
security holes in one place only - all these Linux distributions cannot
be wrong, right?)... _if_ you can share dependencies with other parts of
the system and your system is aware of files you installed (so that it
will not try to install libraries you already have or will not install
applications that depend on different versions of libraries if these
libraries cannot coexist in the same env. (i.e. are conflicting with
each other) - like many Python modules)
> Once a machine of mine goes production, it never gets updated except for
> security releases.
just one question: are you 100% sure that none of the tools you use to
get/install/be notified about/whatever these security updates is written
in Python or has some Python dependencies and Python modules/Eggs
you installed are not breaking them? If yes, everything is ok.
> If I need to have "another app" with a different version I will use a VM
> or a new server.
I meant "another app" as in completely not Pylons related. What if
you'll install a log parser written in Python that should notify you
about problems with this machine and it's not working correctly due to a
bug in one of libraries you installed with your application (and which
overwrote the working one shipped with your distribution)?
--
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-
Mike Orr
> This is interesting. To me the direction this thread took is in reverse.
> Things should be installed globally. It is part of "production". You
> define your deployment, your dependencies and that is what you get. That
> way you don't have to much with silly things like virtualenv.
>
> or a new server.
Well, virtualenv is like a VM, at least in the case where the only
thing you need to isolate is the Python libraries. If you have six
web sites it can be a bit excessive to have six VMs for them,
especially if two are used heavily and two are not used much.
Ideally you'd want to use mature software that has OS packages
available. Then you can just install the OS packages globally and
everything will be fine. The API won't change much between versions
so you can learn it once and that'll last you several years. This is
the case with Apache, MySQLdb, PIL, etc. -- fortunately the things
that are hardest to install locally.
But with immature software, the versions and APIs change too quickly
to do this. If we were to apply this to Pylons, we'd have to stick to
0.9.6, which is not bad but is a dead end long term. So if I have an
0.9.6 application which is running fine and will not have a major
upgrade soon, I'll keep supporting it on 0.9.6 as long as I can. But
new applications I'll write for 0.9.7 because it's close to final, and
to avoid writing it twice (for 0.9.6 now, then upgrading to 0.9.7
later). Plus there may be some bugfixes or new features in 0.9.7 that
this application needs now or might need in the future. So if I
deploy both the new and the older application, right there I've got
incompatible library requirements and thus the need for virtualenv (or
virtual servers, or a fake user for each application).
--
Mike Orr <slugg...@gmail.com>