Package in both setup_requires and install_requires will not be installed
Joshua Boverhof previously reported this in <http://mail.python.org/pipermail/distutils-sig/2007-March/007436.html>. If you specify a package in setup_requires it will be built in the current directory. But even if it is in install_requires as well, it won't be installed because the requirement is already satisfied at setup time by the package in the build directory. Is there a workaround for this?
Michael Hoffman wrote:
If you specify a package in setup_requires it will be built in the current directory. But even if it is in install_requires as well, it won't be installed because the requirement is already satisfied at setup time by the package in the build directory.
I came up with this workaround: from setuptools.command.install import install class SubprocessEasyInstall(install): def run(self): install.run(self) args = [sys.executable, "-m", "easy_install"] + setup_requires check_call(args) And in the setup() call, ensure you include: cmdclass=dict(install=SubprocessEasyInstall) This will easy_install the setup_requires in a separate process which is unpolluted by the distributions already downloaded during setup.
At 12:42 AM 9/18/2007 +0100, Michael Hoffman wrote:
Michael Hoffman wrote:
If you specify a package in setup_requires it will be built in the current directory. But even if it is in install_requires as well, it won't be installed because the requirement is already satisfied at setup time by the package in the build directory.
I came up with this workaround:
from setuptools.command.install import install
class SubprocessEasyInstall(install): def run(self): install.run(self)
args = [sys.executable, "-m", "easy_install"] + setup_requires check_call(args)
And in the setup() call, ensure you include:
cmdclass=dict(install=SubprocessEasyInstall)
This will easy_install the setup_requires in a separate process which is unpolluted by the distributions already downloaded during setup.
Don't do this. It will do evil things if for example someone runs "setup.py install --help", or uses indeed any options or arguments to 'install' at all. It will also break the bdist_rpm, bdist_wininst, and other commands, which invoke 'install' as a subcommand, with various options set.
Phillip J. Eby wrote:
At 12:42 AM 9/18/2007 +0100, Michael Hoffman wrote:
Michael Hoffman wrote:
If you specify a package in setup_requires it will be built in the current directory. But even if it is in install_requires as well, it won't be installed because the requirement is already satisfied at setup time by the package in the build directory. I came up with this workaround:
from setuptools.command.install import install class SubprocessEasyInstall(install): def run(self): install.run(self)
args = [sys.executable, "-m", "easy_install"] + setup_requires check_call(args)
And in the setup() call, ensure you include:
cmdclass=dict(install=SubprocessEasyInstall)
This will easy_install the setup_requires in a separate process which is unpolluted by the distributions already downloaded during setup.
Don't do this. It will do evil things if for example someone runs "setup.py install --help", or uses indeed any options or arguments to 'install' at all.
It will also break the bdist_rpm, bdist_wininst, and other commands, which invoke 'install' as a subcommand, with various options set.
Would you like to suggest a better workaround? I'd rather avoid doing this but the even consequences you outline are better to me than ``setup.py install`` failing to install the specified prerequisites. Thanks, Michael
At 09:26 PM 10/13/2007 +0100, Michael Hoffman wrote:
Phillip J. Eby wrote:
At 12:42 AM 9/18/2007 +0100, Michael Hoffman wrote:
Michael Hoffman wrote:
If you specify a package in setup_requires it will be built in the current directory. But even if it is in install_requires as well, it won't be installed because the requirement is already satisfied at setup time by the package in the build directory. I came up with this workaround:
from setuptools.command.install import install class SubprocessEasyInstall(install): def run(self): install.run(self)
args = [sys.executable, "-m", "easy_install"] + setup_requires check_call(args)
And in the setup() call, ensure you include:
cmdclass=dict(install=SubprocessEasyInstall)
This will easy_install the setup_requires in a separate process which is unpolluted by the distributions already downloaded during setup.
Don't do this. It will do evil things if for example someone runs "setup.py install --help", or uses indeed any options or arguments to 'install' at all.
It will also break the bdist_rpm, bdist_wininst, and other commands, which invoke 'install' as a subcommand, with various options set.
Would you like to suggest a better workaround?
Well, you could do something similar, but look at do_egg_install in setuptools.command.install to see how to construct a good command line for the child process. The full fix is going to be a lot more complicated, unfortunately.
Phillip J. Eby wrote:
At 09:26 PM 10/13/2007 +0100, Michael Hoffman wrote:
Phillip J. Eby wrote:
At 12:42 AM 9/18/2007 +0100, Michael Hoffman wrote:
Michael Hoffman wrote:
If you specify a package in setup_requires it will be built in the current directory. But even if it is in install_requires as well, it won't be installed because the requirement is already satisfied at setup time by the package in the build directory. I came up with this workaround:
from setuptools.command.install import install class SubprocessEasyInstall(install): def run(self): install.run(self)
args = [sys.executable, "-m", "easy_install"] + setup_requires check_call(args)
And in the setup() call, ensure you include:
cmdclass=dict(install=SubprocessEasyInstall)
This will easy_install the setup_requires in a separate process which is unpolluted by the distributions already downloaded during setup. Don't do this. It will do evil things if for example someone runs "setup.py install --help", or uses indeed any options or arguments to 'install' at all.
It will also break the bdist_rpm, bdist_wininst, and other commands, which invoke 'install' as a subcommand, with various options set. Would you like to suggest a better workaround?
Well, you could do something similar, but look at do_egg_install in setuptools.command.install to see how to construct a good command line for the child process.
Alright, I've added this to the to-do list for my app.
The full fix is going to be a lot more complicated, unfortunately.
Yes, that's too bad.
At 11:23 PM 9/15/2007 +0100, Michael Hoffman wrote:
Joshua Boverhof previously reported this in <http://mail.python.org/pipermail/distutils-sig/2007-March/007436.html>.
If you specify a package in setup_requires it will be built in the current directory. But even if it is in install_requires as well, it won't be installed because the requirement is already satisfied at setup time by the package in the build directory.
Is there a workaround for this?
It is now fixed in the trunk and 0.6 branch. I expect to be making a new release in a few weeks, at which time you'll be able to update your ez_setup.py version to require a version of setuptools that doesn't have this problem any more.
Phillip J. Eby wrote:
At 11:23 PM 9/15/2007 +0100, Michael Hoffman wrote:
If you specify a package in setup_requires it will be built in the current directory. But even if it is in install_requires as well, it won't be installed because the requirement is already satisfied at setup time by the package in the build directory.
It is now fixed in the trunk and 0.6 branch. I expect to be making a new release in a few weeks, at which time you'll be able to update your ez_setup.py version to require a version of setuptools that doesn't have this problem any more.
Excellent. Thanks!
participants (2)
-
Michael Hoffman -
Phillip J. Eby