Thanks. I have another question. Now that I'm using distribute, pip handles the requirements correctly, but if I install with:
python setup.py install the dependencies are not installed. This is a bit perplexing. I am trying the scenario where the user has a plain Python installation with no pip, distribute or setuptools (hence installing the old fashioned way). My setup.py looks like this: # Begin of setup.py from distribute_setup import use_setuptools use_setuptools() from setuptools import setup, find_packages setup(..., install_requires=['project1'],...,dependency_links=['http://my.host.org/repository/'],...) # End of setup.py and I took care of including distribute_setup.py in MANIFEST.in, so it is part of the .tar.gz. When attempting to install, I get this $ sudo python setup.py install Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.15.tar.gz Extracting in /tmp/tmp4VDb5n Now working in /tmp/tmp4VDb5n/distribute-0.6.15 Building a Distribute egg in /home/eposse/Downloads/project2-0.1dev /home/eposse/Downloads/proyecto3-0.1dev/distribute-0.6.15-py2.6.egg /usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: 'install_requires' warnings.warn(msg) ... And the dependencies are ignored. I don't understand: I explicitly called use_setuptools in my setup, and as can be seen, distribute is automatically downloaded (albeit installed in a temporary directory), and imported setup from setuptools, but it looks like it is calling the plain distutils setup !? Why is it not calling the distribute/setuptools setup? Is there any way around this? Thanks PS: since 'requires' and 'provides' are not used in any tool, why are they in the official documentation? On Tue, Apr 19, 2011 at 5:18 PM, Carl Meyer <[email protected]> wrote: > On 04/19/2011 04:07 PM, Ernesto Posse wrote: >> 1) using distribute and >> >> setup(..., install_requires=['project1'],..., >> dependency_links=['http://my.host.org/repository/'],...) >> >> installs as expected both project1 and project2, but >> >> pip uninstall project2 >> >> does not uninstall project1. This is quite disappointing, as a user >> may be unaware of dependencies automatically installed, and thus, the >> uninstall leaves behind something that was installed with the bundle. >> I imagine that the idea is that the user may install some other >> package that depends on 'project1' and pip takes the conservative >> approach (is that the case?) but I would have expected for pip or >> distribute or setuptools or distutils to keep some dependency >> reference counter. Does any of these tools have something like that? >> or is it going to be addressed in distutils2? > > No, there's no current Python packaging tool I know of that keeps a > dependency reference counter and automatically uninstalls orphaned > dependencies. The new standard installation format (defined in PEP 376 > and implemented in distutils2) does record whether a package was > installed by explicit user request or as a dependency; combined with > checking dependencies of all other installed packages, this will make it > possible for an uninstaller to implement automatic (or prompted) > dependency uninstalls. > >> 2) if install_requires is missing a dependency (project1), the package >> gets installed without that dependency, but if I add a dependency and >> the user attempts an install (project2) with the updated setup.py >> (listing the new dependency) pip will say that the package (project2) >> is already installed and won't attempt to install the dependencies. Is >> this correct? If so, is there a way to tell pip to install project2's >> dependencies? > > With a real package release, the setup.py metadata should never change > without a version number change. In which case, if you specify the new > version explicitly or use --upgrade, the previous version will be > uninstalled and the new one installed in its place, with dependencies. > (Actually, if you specify --upgrade and you already have the most recent > version installed, it will still uninstall and reinstall it; but this is > actually considered a bug.) > > Carl > _______________________________________________ > Distutils-SIG maillist - [email protected] > http://mail.python.org/mailman/listinfo/distutils-sig > -- Ernesto Posse Modelling and Analysis in Software Engineering School of Computing Queen's University - Kingston, Ontario, Canada _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
