Hello,
On my Ubuntu desktop, httplib2 v0.4.0 is installed system-wide because it's required by many things. However, I need to use v0.6.0 of that package in my Buildout-powered project.
But when I run Buildout, I get this error: ===== VersionConflict: (httplib2 0.4.0 (/usr/lib/pymodules/python2.5), Requirement.parse('httplib2==0.6.0')) =====
I've hit this problem before and what I had done is to remove the system-wide install, which I cannot do this time.
There has to be a way for Buildout to ignore the global install, but I could not find the answer after reading the documentation.
Can you please help me?
Cheers,
On Thu, Mar 11, 2010 at 10:32 AM, Gustavo Narea gustavonarea@2degreesnetwork.com wrote:
Hello,
On my Ubuntu desktop, httplib2 v0.4.0 is installed system-wide because it's required by many things. However, I need to use v0.6.0 of that package in my Buildout-powered project.
But when I run Buildout, I get this error:
VersionConflict: (httplib2 0.4.0 (/usr/lib/pymodules/python2.5), Requirement.parse('httplib2==0.6.0')) =====
I've hit this problem before and what I had done is to remove the system-wide install, which I cannot do this time.
There has to be a way for Buildout to ignore the global install, but I could not find the answer after reading the documentation.
Can you please help me?
There isn't currently an option to get buildout to ignore site-packages, although an option to do that is under review.
Many of us simply avoid using system Python installs. I personally always have clean Python installs, independent from system Python, that I use for applications.
Jim
Jim Fulton wrote:
On Thu, Mar 11, 2010 at 10:32 AM, Gustavo Narea gustavonarea@2degreesnetwork.com wrote:
Hello,
On my Ubuntu desktop, httplib2 v0.4.0 is installed system-wide because it's required by many things. However, I need to use v0.6.0 of that package in my Buildout-powered project.
But when I run Buildout, I get this error:
VersionConflict: (httplib2 0.4.0 (/usr/lib/pymodules/python2.5), Requirement.parse('httplib2==0.6.0')) =====
I've hit this problem before and what I had done is to remove the system-wide install, which I cannot do this time.
There has to be a way for Buildout to ignore the global install, but I could not find the answer after reading the documentation.
Can you please help me?
There isn't currently an option to get buildout to ignore site-packages, although an option to do that is under review.
Many of us simply avoid using system Python installs. I personally always have clean Python installs, independent from system Python, that I use for applications.
I hope you merge that option ASAP. :)
The problem is not "us" who have pristine global Python's. It's "them" that we give our buildouts to and expect them to work the same as they did on our own machine: end users (Plone's installers are buildouts now, for example), sysadmins, and new developers.
Martin
Hi,
On Thu, Mar 11, 2010 at 17:14, Martin Aspeli optilude+lists@gmail.com wrote:
Jim Fulton wrote:
On Thu, Mar 11, 2010 at 10:32 AM, Gustavo Narea gustavonarea@2degreesnetwork.com wrote:
Hello,
On my Ubuntu desktop, httplib2 v0.4.0 is installed system-wide because it's required by many things. However, I need to use v0.6.0 of that package in my Buildout-powered project.
But when I run Buildout, I get this error:
VersionConflict: (httplib2 0.4.0 (/usr/lib/pymodules/python2.5), Requirement.parse('httplib2==0.6.0')) =====
I've hit this problem before and what I had done is to remove the system-wide install, which I cannot do this time.
There has to be a way for Buildout to ignore the global install, but I could not find the answer after reading the documentation.
Can you please help me?
There isn't currently an option to get buildout to ignore site-packages, although an option to do that is under review.
Will this option be able to disregard the system-wide setuptools/Distribute? Some systems have old setuptools versions and users are unable to update (or better said, uncomfortable with updating). When we give them a package that has a newer bootstrap.py (http://python-distribute.org/bootstrap.py for example), they can't bootstrap the project.
And what does "under review" mean? Is there a development version of bootstrap.py somewhere that we use to can try the new feature?
Many of us simply avoid using system Python installs. I personally always have clean Python installs, independent from system Python, that I use for applications.
I hope you merge that option ASAP. :)
The problem is not "us" who have pristine global Python's. It's "them" that we give our buildouts to and expect them to work the same as they did on our own machine: end users (Plone's installers are buildouts now, for example), sysadmins, and new developers.
I absolutely agree with Martin Aspeli here.
Bests, Attila
On Thu, Mar 11, 2010 at 11:44 AM, Attila Oláh attilaolah@gmail.com wrote: ...
There isn't currently an option to get buildout to ignore site-packages, although an option to do that is under review.
Will this option be able to disregard the system-wide setuptools/Distribute?
Yes.
...
And what does "under review" mean? Is there a development version of bootstrap.py somewhere that we use to can try the new feature?
It means that there is a branch with the change that I need to review and merge.
Jim
Jim Fulton wrote:
And what does "under review" mean? Is there a development version of bootstrap.py somewhere that we use to can try the new feature?
It means that there is a branch with the change that I need to review and merge.
Anything we can do to help speed that up?
Chris
Thank you, Jim.
I think I'll have to have a separate Python.
Thank you!
On 11/03/10 16:00, Jim Fulton wrote:
There isn't currently an option to get buildout to ignore site-packages, although an option to do that is under review.
Many of us simply avoid using system Python installs. I personally always have clean Python installs, independent from system Python, that I use for applications.
On Thu, 2010-03-11 at 15:32 +0000, Gustavo Narea wrote:
Hello,
On my Ubuntu desktop, httplib2 v0.4.0 is installed system-wide because it's required by many things. However, I need to use v0.6.0 of that package in my Buildout-powered project.
But when I run Buildout, I get this error:
VersionConflict: (httplib2 0.4.0 (/usr/lib/pymodules/python2.5), Requirement.parse('httplib2==0.6.0')) =====
I've hit this problem before and what I had done is to remove the system-wide install, which I cannot do this time.
There has to be a way for Buildout to ignore the global install, but I could not find the answer after reading the documentation.
use virtualenv with --no-site-packages option, and run your buildout with the python from your virtualenv
http://pypi.python.org/pypi/virtualenv
Thanks, Yonsy. However I already do that :/
On 11/03/10 16:21, Yonsy Solis wrote:
use virtualenv with --no-site-packages option, and run your buildout with the python from your virtualenv
On Thu, 2010-03-11 at 16:24 +0000, Gustavo Narea wrote:
Thanks, Yonsy. However I already do that :/
don't work ? strange,
with --no-site-packages u have a totally isolated python ...
the same error happens ?
On Thu, Mar 11, 2010 at 17:46, Yonsy Solis yonsy@aureal.pe wrote:
with --no-site-packages u have a totally isolated python ...
Totally isolated? Not really. The only solution is, like Jim said, to install a new Python[1].
[1] Basic steps : - install the package build-essential - download the source package - tar xvfz <package> ; cd <package> ; ./configure --prefix=/your/path; make; make install
Gustavo Narea wrote:
On 11/03/10 16:21, Yonsy Solis wrote:
use virtualenv with --no-site-packages option, and run your buildout with the python from your virtualenv
Thanks, Yonsy. However I already do that :/
Huh? A virtual_env with --no-site-packages should isolate you from everything in site-packages.
If it doesn't, please file a bug with the virutal_env guys!
Chris
It seems to me that once this feature is integrated, there will be less incentive to use virtualenv.
What cool virtualenv features are left if buildout can do the --no-site-package?
On Sat, Mar 27, 2010 at 7:30 PM, Chris Withers chris@simplistix.co.uk wrote:
Gustavo Narea wrote:
On 11/03/10 16:21, Yonsy Solis wrote:
use virtualenv with --no-site-packages option, and run your buildout with the python from your virtualenv
Thanks, Yonsy. However I already do that :/
Huh? A virtual_env with --no-site-packages should isolate you from everything in site-packages.
If it doesn't, please file a bug with the virutal_env guys!
Chris
-- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
On Sat, Mar 27, 2010 at 09:15:32PM +0100, Jean Daniel wrote:
It seems to me that once this feature is integrated, there will be less incentive to use virtualenv.
What cool virtualenv features are left if buildout can do the --no-site-package?
I can easy_install a one-off development tool (RunSnakeRun, restview, zodbbrowser, zest.releaser, z3c.dependencychecker, a million others) without having to
* edit a config file * re-run buildout and wait 15 seconds longer than it would take otherwise [1] * remember to revert my changes lest I commit them and force my tool choice on all developers of the project [2]
[1] on my project, a do-nothing-because-nothing-changed bin/buildout with newest=false still takes 15 seconds
[2] admittedly, I could create a new empty config file, have it extend buildout.cfg, add the extra eggs where necessary, and remember to run bin/buildout -c my.cfg. In practice I always forget the -c and only notice when I try to use my extra tools and find them missing, which breaks the flow and imposes a 15 second delay.
Don't get the wrong impression; despite occasional frustrations, buildout is a good tool that does things virtualenv doesn't do, and I prefer to use buildout for all my Python packages once they stop being trivially simple. Buildout's killer feature is the shared egg cache.
Marius Gedminas
Marius Gedminas wrote:
- edit a config file
I tend to create new mini-buildouts for this kind of thing...
- re-run buildout and wait 15 seconds longer than it would take otherwise [1]
I believe you're looking for either -o, if you have the eggs already, or the aforementioned mind buildout.cfg ;-)
[2] admittedly, I could create a new empty config file, have it extend buildout.cfg,
Why extend? If you're screwing around you only want a small set of eggs...
Don't get the wrong impression; despite occasional frustrations, buildout is a good tool that does things virtualenv doesn't do, and I prefer to use buildout for all my Python packages once they stop being trivially simple. Buildout's killer feature is the shared egg cache.
Right, I just wish it didn't have to build the monster sys.path[:]= and have its own custom scripts when all you want is an interpreter ;-)
Chris
-
Attila Oláh -
Chris Withers -
Gustavo Narea -
Jean Daniel -
Jim Fulton -
Marius Gedminas -
Martin Aspeli -
Sebastien Douche -
Yonsy Solis