Is Django more popular than Pylons?
walterbyrd
Gael Pasgrimaud
http://groups.google.com/group/pylons-discuss/browse_thread/thread/8fbf7e2037d1a53c
--
Gael
On Mon, Jan 19, 2009 at 1:05 AM, walterbyrd <walte...@iname.com> wrote:
>
> And if so, why?
>
>
> >
>
jerry
And that's because if the same question is asked in a Django group,
you'll probably get far more similar trolls.
Jerry
Jorge Vargas
yes, so does php, your point?
Patrick
creating my first dynamic site. Pylons is a great help to me and is
helping me to put bread on the table with my small business.
I love open source but I can imagine that it must be hard to be an open
source developer with people using your code and then kicking you in the
face with criticism or just plain general insensitivity.
For what is it worth, I would like to take a minute to that my
benefactors-Patrick
Mike Orr
Everybody who uses Pylons knows that other frameworks exist and had
maybe tried one or two others, but has made a conscious choice that
they like Pylons' style better. A lot of Django fans have done the
same of course, but a lot of other Django fans have not really looked
into any other frameworks, they just came to Django from Rails or PHP
because they heard about it first and didn't look any further.
--
Mike Orr <slugg...@gmail.com>
Mario Ruggier
> On Sun, Jan 18, 2009 at 4:05 PM, walterbyrd <walte...@iname.com>
> wrote:
>>
>> And if so, why?
>
> Everybody who uses Pylons knows that other frameworks exist and had
> maybe tried one or two others, but has made a conscious choice that
> they like Pylons' style better.
Hi Mike, I think I understand perfectly the intention of what you are
saying here, but the last almost off-handish reference to "style" made
me do a double-take on what you mean... What I do not "understand" is
that given all the noisy promises of an ideal world where all python
web applications are built following wsgi and installed with
setuptools, the difference we are talking about cannot be simply
written off as a matter of "style", but more architectural and
philosophical. Pylons has, with the best of intentions, tried to
embrace the "new" open-architecture as fully as possible. And, it pays
and will continue to pay a fairly high price for that choice...
Example of past price paid, just look at the number of what-should-be-
a-non-issue installation problems in the mail archive. Example of
price to pay, iiuc, apparently wsgi/paste/whatever has some unicode
issues, so pylons has to wait for those to be fixed and third-party
released to be able to even consider 3.0? Excuse me?
I fully respect the choices that pylons makes, and almost always I am
fine with them. There is anyway always a judgement call between wide-
open genericity and narrower-scoped simplicity, and there is no
"right" balance. Pylons probably errs towards the first, and django
towards the second.
But simplicity is very slippery, and very easily lost. The promise of
generic inter-operational components more often than not exacts a
higher price than what it gives back. How have the wsgi promises of
inter-changeable web app building blocks measured up against the
overhead from added complexities and issues? If you take for example
qp, one of the few non-wsgi framework around, it strikes an amazing
balance between simplicity and genericity, and it is not hindered by
possibly-interfering impositions of a generic api such as wsgi. It can
be used with or without the Durus object database that accompanies it,
but it can (probably) just as easily also be used with sqlalchemy or
any other ORM. QP also adopts the more robust single-thread multi-
process approach to building apps, a choice that wsgi deems (pls
correct and excuse me if I am saying something silly here!) to not
particularly cater for. But, deployment of a qp app cannot be
easier... SCGI works like a charm e.g. over apache, and is even more
charming over lighttpd that has builtin support for it. Its "framework
api" is grokkable in minutes... plus, a small additional fact, qp +
durus (and the associated templating utility, qpy) have been available
for python 3.0 since --day-1--, that is since the official first
release date of python 3.0.
All I am saying is that buying into a new way of doing things is fine
but one has to be able to look back and sans-emotions admit what has
actually worked and what has not. And, if at the beginning it the
motivation was philosophical, playing it down in hindsight to a matter
of style indicates to me that it has not all worked as well as hoped.
> A lot of Django fans have done the
> same of course, but a lot of other Django fans have not really looked
> into any other frameworks, they just came to Django from Rails or PHP
> because they heard about it first and didn't look any further.
But this is a sociological fact, true of all software where the user-
base goes beyond a certain "mass" -- blind following of the trend.
But, I would add it is probably a good thing... everybody must go down
his own path, and if django attracts people from rails/php, those same
people will, after some experience with django forge their own
opinions and preferences... and maybe some of them will then discover,
and prefer, pylons. Or maybe they'll just go back to php ;-!!
mario
> --
> Mike Orr <slugg...@gmail.com>
Michael Bayer
usage of WSGI in the generic sense doesn't complicate things to any
degree - the spec is just a single function call. If there are Py3K
issues in Paste, lets first make it clear that *every* application
that deals explicitly with character encodings needs code changes to
work with Py3K. I can assure you any issues Paste has in this area
will be resolved deftly and correctly by Ian Bicking.
The only price Pylons is paying is it assumes the developer would like
to consider how his application should be architected, instead of
those decisions being made implicitly and invisibly. This is a
cultural situation created by the dominance of PHP, a decidedly "don't
make me think / I didn't even know there was anything to think about"
platform, in the LAMP world.
If and when other cultures, such as that of the Java and .NET/C#
communities (the theme of which would be, "we know how to code, let's
do this exactly the way we think it should be"), decide to embrace
Python more fully, projects like Pylons will establish a more
prominent userbase. The most popular web frameworks in the Java
community, such as Struts2 (nothing like Struts1) and Spring MVC,
translate conceptually to a WSGI stack very directly.
On Jan 23, 8:16 am, Mario Ruggier <ma...@ruggier.org> wrote:
> On Jan 19, 2009, at 8:05 PM, Mike Orr wrote:
>
chris mollis
Joshua D. Drake
> The only price Pylons is paying is it assumes the developer would like
> to consider how his application should be architected, instead of
> those decisions being made implicitly and invisibly. This is a
> cultural situation created by the dominance of PHP, a decidedly "don't
> make me think / I didn't even know there was anything to think about"
> platform, in the LAMP world.
>
> If and when other cultures, such as that of the Java and .NET/C#
> communities (the theme of which would be, "we know how to code, let's
> do this exactly the way we think it should be"), decide to embrace
> Python more fully, projects like Pylons will establish a more
> prominent userbase. The most popular web frameworks in the Java
> community, such as Struts2 (nothing like Struts1) and Spring MVC,
> translate conceptually to a WSGI stack very directly.
Very well put.
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
Jorge Vargas
>
> On Jan 19, 2009, at 8:05 PM, Mike Orr wrote:
>> On Sun, Jan 18, 2009 at 4:05 PM, walterbyrd <walte...@iname.com>
>> wrote:
>>>
>>> And if so, why?
>>
>> Everybody who uses Pylons knows that other frameworks exist and had
>> maybe tried one or two others, but has made a conscious choice that
>> they like Pylons' style better.
>
> Hi Mike, I think I understand perfectly the intention of what you are
> saying here, but the last almost off-handish reference to "style" made
> me do a double-take on what you mean... What I do not "understand" is
> that given all the noisy promises of an ideal world where all python
> web applications are built following wsgi and installed with
> setuptools, the difference we are talking about cannot be simply
> written off as a matter of "style", but more architectural and
> philosophical. Pylons has, with the best of intentions, tried to
> embrace the "new" open-architecture as fully as possible. And, it pays
> and will continue to pay a fairly high price for that choice...
> Example of past price paid, just look at the number of what-should-be-
> a-non-issue installation problems in the mail archive.
search django list for geodjango, search for "using app X with app Y",
installations issues always happen when you have more than one source
of packages. That said most of the "installation issues" on this list
are simply people trying to get authkit going enough said.
> Example of
> price to pay, iiuc, apparently wsgi/paste/whatever has some unicode
> issues, so pylons has to wait for those to be fixed and third-party
> released to be able to even consider 3.0? Excuse me?
>
now this is interesting. I actually see that as an advantage. if some
some reason paste becomes an evil thing, you simply drop it and
replace it for something better. It happen to SO with SA, it has
happen several times with templating engines. webob was introduced to
pylons and no one didn't even notice. If you look at the other side of
the track you just can't get rid of django ORM without killing half
the framework.
So the price to pay is that you have to think what components you have
to use instead of simply following the needs of a newspaper editorial
room. Ok that sounded derogative :) Django is very good at some
things, pylons is good at all things and that comes with a price, but
a good price to pay.
Mario Ruggier
superficial question of style. It goes beyond that, and there is a
price to pay -- and that the price is generally justifiable. And, as
Micheal eloquently states, given the looming horizon, the line taken
by pylons promises to attract more and more people in the future, as
more people from other worlds will learn about what py3k really
offers. But then again, the more eclipsed java developers come to
pylons, the harder it will be for pylons to dearly hold on to that
slippery simplicity... !
I of course agree with Jorge's argument on the advantages of a non-
monolithic framework And yes of course that having different
components to install will naturally give rise to numerous
installation problems. But, it remains that that there were several
strange setuptools-related problems when I first started to get pylons
projects going, problems that I was not interested about in the very
least. The bugginess on that front seems to be getting less, but
without getting into endless religious discussions you have to admit
there is an added sometimes-cryptic layer added about how packages are
installed, where the py source code is, etc. And, "simplicity" suffers
a little hit as a consequence.
As for replacing components, I completely appreciate the possibility
of doing so. If pylons did not allow me to use *the* state-of-the-art
templating (that of course is http://evoque.gizmojo.org/ ;-) it would
certainly be a less attractive framework. However most of the docs,
default settings etc are geared towards a "default profile" of
components, namely mako and SA. Go out of that mould, and you may have
integration puzzles to solve, or in any case you are still dependent
on the "unused" package anyway (in the case of mako). As for paste, I
certainly do not want to fiddle with replacing the builtin dev web
server -- has anyone (apart from pylons developers that is) even
considered trying?
Small anecdote about unicode issues, and migration to Py3k... unicode
is unicode, be it py2 or py3. Nothing has changed conceptually in py3
on this, except that all strings are now unicode -- something that has
been a best practice in py2 since how many years? As for "porting"
evoque to py3k, once I got actually started on it, I ended up getting
it done in one sitting. It was easy, mostly a superficial set of
import and naming adjustments. Evoque also has a little library to
automatically "guess" (with hints allowed) the encoding of a text
file, so it certainly has to deal with encodings. But it was easy to
do because the application internally was in the first place all
unicode anyway.
Cheers, mario
Mike Orr
>
> From what you all say I think we do agree that it is not just a
> superficial question of style.
There are two aspects to the style. One is the philosophy of WSGI to
the core, and thus the choice of Paste as the first (and still only?)
generic wayto configure and launch WSGI applications.
The other aspect is Pylons' particular API of Routes, action
signatures, context globals, render_mako, use of FormEncode and
WebHelpers, etc. I came to Pylons because of the former, but others
may use it because of the latter.
> It goes beyond that, and there is a
> price to pay -- and that the price is generally justifiable. And, as
> Micheal eloquently states, given the looming horizon, the line taken
> by pylons promises to attract more and more people in the future, as
> more people from other worlds will learn about what py3k really
> offers. But then again, the more eclipsed java developers come to
> pylons, the harder it will be for pylons to dearly hold on to that
> slippery simplicity... !
>
> I of course agree with Jorge's argument on the advantages of a non-
> monolithic framework And yes of course that having different
> components to install will naturally give rise to numerous
> installation problems. But, it remains that that there were several
> strange setuptools-related problems when I first started to get pylons
> projects going, problems that I was not interested about in the very
> least.
I hate to pass the buck, but this is Python's fault for not having
reliable package management built in. There's nothing Pylons can do
about it except switch to another programming language.
> Small anecdote about unicode issues, and migration to Py3k... unicode
> is unicode, be it py2 or py3. Nothing has changed conceptually in py3
> on this, except that all strings are now unicode -- something that has
> been a best practice in py2 since how many years?
I think the issue is that the headers are defined as strings but
they're actually bytestrings in Python 3. Python changed the
semantics of what a string is, and now that strings and bytestrings
don't autoconvert it becomes a users' issue.
--
Mike Orr <slugg...@gmail.com>
Noah Gift
>> monolithic framework And yes of course that having different
>> components to install will naturally give rise to numerous
>> installation problems. But, it remains that that there were several
>> strange setuptools-related problems when I first started to get pylons
>> projects going, problems that I was not interested about in the very
>> least.
>
> I hate to pass the buck, but this is Python's fault for not having
> reliable package management built in. There's nothing Pylons can do
> about it except switch to another programming language.
Pylons has a nice new website, and with it is a direct link to a
continuous integration status page, via Buildbot. Would it perhaps be
useful to include the installation of Pylons into the continuous
integration system? It does seem like various people have had issues
getting Pylons to build successfully at one point or another, and this
is equally important as whether the code works, in my opinion.
There is a simple way to fix this problem. You work around the Python
packaging system, or at least only have core developers use it to
assemble a build that was generated from a continuous integration
system. Then tell easy_install, or plain distutils, to just install
the tar file. This is what Django does, and it isn't exactly elegant,
but then again, I have never had a problem installing Django, and I
have had a problem installing Pylons.
Akira Kitada
> I hate to pass the buck, but this is Python's fault for not having
> reliable package management built in. There's nothing Pylons can do
> about it except switch to another programming language.
What programming language has a reliable package management system built in?
Why do you think distutils is not reliable?
Isn't it enough to use the package management systen you system provides
when you need complete and rigorous one?
Mike Orr
That's what Guido says, and it's why we're at an impasse. Distutils
is fine if you just need to download one or two packages and "python
setup.py install" them. But that doesn't scale when a package has a
dozen dependencies that recursively have dependencies. Without
Setuptools, Python and TurboGears couldn't exist, and Zope and Twisted
would not have been able to split themselves into several packages.
People coming to Python from Perl and Ruby expect to be able to just
run a command to download and install a package. That problem was
solved ten years ago, so why does Python still not have it standard?
If Setuptools and Virtualenv or the equivalent were built into Python,
you could trust that every computer that has successfully installed
Python can install packages and make virtual environments the same
way. That would eliminate 2/3 of the problems users have when
installing Pylons, and the subsequent need to explain the problems and
workarounds in the installation docs. And the problems are different
on Windows vs Mac vs Linux, and App Engine adds another dimension. At
work people say, "Half the trouble of Pylons is installing it", and I
often have to help them install it in person because otherwise they
get stuck at some error message and have no idea what to do.
--
Mike Orr <slugg...@gmail.com>
Eric Lemoine
I agree that it'd be good to have virtualenv shipped with Python. I
wish I did have to tell my Pylons application users to first download
virtualenv, dearchive it, extract virtualenv.py, etc.
Cheers,
Eric
2009/1/27, Mike Orr <slugg...@gmail.com>:
Noah Gift
> on Windows vs Mac vs Linux, and App Engine adds another dimension. At
> work people say, "Half the trouble of Pylons is installing it", and I
> often have to help them install it in person because otherwise they
> get stuck at some error message and have no idea what to do.
a mac buildbot with a linux and windows virtual machine? You
easy_install pylons, which in a sense is a build, and then run tests,
which a few standard configurations? Maybe hardware could get donated
for this.
>
> --
> Mike Orr <slugg...@gmail.com>
>
> >
>
--
Cheers,
Noah
Chris Miles
On 28/01/2009, at 6:40 PM, Noah Gift wrote:
>
> . And the problems are different
>> on Windows vs Mac vs Linux, and App Engine adds another dimension.
>> At
>> work people say, "Half the trouble of Pylons is installing it", and I
>> often have to help them install it in person because otherwise they
>> get stuck at some error message and have no idea what to do.
>
> Not to belabor the point, but couldn't this be automatically tested on
> a mac buildbot with a linux and windows virtual machine? You
> easy_install pylons, which in a sense is a build, and then run tests,
> which a few standard configurations? Maybe hardware could get donated
> for this.
Snakebite might be suitable for this.
http://www.snakebite.org/
Cheers
Chris Miles
Ben Bangert
> I agree that it'd be good to have virtualenv shipped with Python. I
> wish I did have to tell my Pylons application users to first download
> virtualenv, dearchive it, extract virtualenv.py, etc.
Ah, on that front, some good news if they're running linux/OSX. A one-
liner will download a bootstrap script, make a new virtualenv, and
setup Pylons inside it:
curl http://pylonshq.com/download/0.9.7/go-pylons.py | python - mydevenv
Where mydevenv is the name of the virtualenv. I actually like this
approach so much, I use it whenever deploying a Pylons app to first
setup Pylons in a new virtualenv. Note that the installation docs
document this:
http://pylonshq.com/docs/en/0.9.7/gettingstarted/#installing
Note if you take a look inside the go-pylons script, there's a section
where you can declare commands to run in the new virtualenv, so you
could further customize the bootstrap script to get your own Pylons
app, install its dependencies, etc.
Cheers,
Ben
Gael Pasgrimaud
I use zc.buildout to install/deploy my pylons apps.
Are you guys interested in a "how to install Pylons with zc.buildout" ?
--
Gael
Wyatt Baldwin
> Hi,
>
> I use zc.buildout to install/deploy my pylons apps.
>
> Are you guys interested in a "how to install Pylons with zc.buildout" ?
Mike Orr
Ditto. Buildout has not gotten the usage it deserves because many
potential users find it a pain to learn its configuration syntax and
its way of doing things.
--
Mike Orr <slugg...@gmail.com>
Akira Kitada
> is fine if you just need to download one or two packages and "python
> setup.py install" them. But that doesn't scale when a package has a
> dozen dependencies that recursively have dependencies. Without
> Setuptools, Python and TurboGears couldn't exist, and Zope and Twisted
> would not have been able to split themselves into several packages.
For Pylons/TurboGears users, their system's package system would be
preferable to setuptools', because it's robost and easier to manage
their packages easily.
That said, setuptools+virtualenv might be good for developers,
and it would be nice to have dependency support in distutils.
PEP 345 says distutils have "requires" metadata,
so at least we could expect it to be added in near future,
if someone write a patch for it.
Mike Orr
>
>> That's what Guido says, and it's why we're at an impasse. Distutils
>> is fine if you just need to download one or two packages and "python
>> setup.py install" them. But that doesn't scale when a package has a
>> dozen dependencies that recursively have dependencies. Without
>> Setuptools, Python and TurboGears couldn't exist, and Zope and Twisted
>> would not have been able to split themselves into several packages.
>
> Why not package management system on the system like apt/yum/MacPorts?
> For Pylons/TurboGears users, their system's package system would be
> preferable to setuptools', because it's robost and easier to manage
> their packages easily.
Because distro release cycles can't keep up with the rate of change in
Python packages. You may need a version that the distro doesn't
provide. Even if it's just one package, you're into local-install
land.
Also, distro packages can only be one version at a time, whereas you
may have one application that needs one version and another
application that needs another. Virtualenv handles this but OS
packages don't.
OS packages could be made to allow multiple versions side by side
("easy_install -m"), and each app could use pkg_resources.require() to
put the version it needs onto sys.path. But Setuptools is particularly
fragile in this area so few applications have gone this route, plus
users do not expect to have to "require" packages by default. And pip
shows an installation structure that's arguably better but is
incompatible with multi-versioning.
In production, I've gone to always using virtualenvs. That way if I
install a new website with different library versions, I don't have to
worry about potentially breaking existing sites. I use OS packages
only for things that are particularly difficult to install (MySQLdb,
LDAP, PIL). Fortunately these are pretty version-independent, so all
applications can use them.
--
Mike Orr <slugg...@gmail.com>
Wyatt Baldwin
> On Wed, Jan 28, 2009 at 3:37 PM, Akira Kitada <akit...@gmail.com> wrote:
>
> [snip]
> In production, I've gone to always using virtualenvs. That way if I
> install a new website with different library versions, I don't have to
> worry about potentially breaking existing sites. I use OS packages
> only for things that are particularly difficult to install (MySQLdb,
> LDAP, PIL). Fortunately these are pretty version-independent, so all
> applications can use them.
great.
Jorge Vargas
same here works great for dev and prod across any OS.
Damjan
(doesn't need to exist), for example:
export PYTHONUSERBASE=$HOME/mydev/
pip.py install FormAlchemy
Now I do have in ~/.pydistutils.cfg
[install]
user=True
It's similar to virtualenv, but kind-of more clean, and doesn't copy
the whole python executable in each env (which I never liked).
To switch to another env, just reset the variable.
Mike Orr
I haven't heard of this. Has anybody else compared it with Virtualenv
to see its advantages and disadvantages? What exactly does it do?
Does it do the same thing that the custom Python interpreter in the
virtualenv does, or less?
--
Mike Orr <slugg...@gmail.com>
Mike Orr
Oh, this is the same as the per-user install directory?
http://www.python.org/dev/peps/pep-0370/
I thought there could be only one site-packages per user, not multiple
ones per application.
--
Mike Orr <slugg...@gmail.com>
Damjan
>
> I thought there could be only one site-packages per user, not multiple
> ones per application.
you are using, so you can have as many as you want (the *user* as such
doesn't matter any).
I've been using it for some time, and looks good to me, haven't seen
any problems.
It's much cleaner too.. no copies of anything (neither the
interpreter, neither the other modules that virtualenv copies or
links), no hacks in some other modules.
Kless
doesn't works on virtualenv. If if works then would be another great
advantage :)
On 29 ene, 16:39, Damjan <gdam...@gmail.com> wrote:
> > Oh, this is the same as the per-user install directory?http://www.python.org/dev/peps/pep-0370/
Bernard Rankin
>
> Damjan, and does ipython works from $PYTHONUSERBASE? because it
> doesn't works on virtualenv. If if works then would be another great
> advantage :)
>
Ipython seems to work fine for me on virtualenv.... What about it does not work for you?
Also, don't forget that virtualenv, also sets the shell's path to include a local bin directory as well.
Wyatt Baldwin
installed into the virtualenv, though. Also, I think once you install
it, you need to deactivate then reactivate the virtualenv.
Gael Pasgrimaud
http://www.gawel.org/howtos/howto-install-pylons-with-buildout
Don't know if this doc have a place on pylonshq since the official way
to install pylons is with virtualenv.
Mike Orr
>
> Here it is:
>
> http://www.gawel.org/howtos/howto-install-pylons-with-buildout
>
> Don't know if this doc have a place on pylonshq since the official way
> to install pylons is with virtualenv.
It belongs in the Pylons Cookbook initially. After that the
developers will decide whether to include it in the official docs or
link to it. I think they will at least link to it. If the original
source is ReST or HTML, you can include it in a wiki page via the
{rst}...{rst} or {html}...{html} tags I think. Or if that's too
cumbersome, you can just link to it from an appropriate Cookbook page.
Thank you for taking the time to write this.
--
Mike Orr <slugg...@gmail.com>
Gael Pasgrimaud
>
> On Thu, Jan 29, 2009 at 12:55 PM, Gael Pasgrimaud <ga...@gawel.org> wrote:
>>
>> Here it is:
>>
>> http://www.gawel.org/howtos/howto-install-pylons-with-buildout
>>
>> Don't know if this doc have a place on pylonshq since the official way
>> to install pylons is with virtualenv.
>
> It belongs in the Pylons Cookbook initially. After that the
> developers will decide whether to include it in the official docs or
> link to it. I think they will at least link to it. If the original
> source is ReST or HTML, you can include it in a wiki page via the
> {rst}...{rst} or {html}...{html} tags I think. Or if that's too
> cumbersome, you can just link to it from an appropriate Cookbook page.
http://wiki.pylonshq.com/display/pylonscommunity/Howto+install+Pylons+with+buildout
>
> Thank you for taking the time to write this.
understand but when you understand it you never have all the problems
that this thread refer to.
>
> --
> Mike Orr <slugg...@gmail.com>
>
> >
>
Wichert Akkerman
>
> Here it is:
>
> http://www.gawel.org/howtos/howto-install-pylons-with-buildout
It might be useful to document using collective.recipe.modwsgi as well.
That makes it trivial to use pylons with mod_wsgi from a buildout
environment.
Wichert.
--
Wichert Akkerman <wic...@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Gael Pasgrimaud
> Previously Gael Pasgrimaud wrote:
>>
>> Here it is:
>>
>> http://www.gawel.org/howtos/howto-install-pylons-with-buildout
>
> It might be useful to document using collective.recipe.modwsgi as well.
> That makes it trivial to use pylons with mod_wsgi from a buildout
> environment.
>
I always use mod_proxy but I can add a pointer in the tips section.
Look like an example already exist on the pypi page.
I can also add a tips to use collective.recipe.supervisor to control a
pylons process
Do you see any other useful recipe ?
Damjan
> doesn't works on virtualenv. If if works then would be another great
> advantage :)
it can import the modules in my USERBASE, no problem.
So you don't even need to install it in the virtual environment.
Akira Kitada
>> For Pylons/TurboGears users, their system's package system would be
>> preferable to setuptools', because it's robost and easier to manage
>> their packages easily.
>
> Because distro release cycles can't keep up with the rate of change in
> Python packages. You may need a version that the distro doesn't
> provide. Even if it's just one package, you're into local-install
> land.
You can create any OS packages yourself.
> Also, distro packages can only be one version at a time, whereas you
> may have one application that needs one version and another
> application that needs another. Virtualenv handles this but OS
> packages don't.
You're right but I haven't ever needed multiple versions of a
package on one box, so I can't comment on this.
Thanks,
Kless
Now I only waits that Ubuntu adds Py 2.6 very soon.