setuptools docs: Declaring Dependencies
I'm reading through the documentation some... Regarding this:
Note, by the way, that if you declare your dependencies in setup.py, you do not need to use the require() function in your scripts or modules, as long as you either install the project or use setup.py develop to do development work on it. (See "Development Mode" below for more details on using setup.py develop.)
I don't think this is quite true. In particular, I've noticed if you install a package A --multi-version, it fulfills the requirement for A. And if you have a package B that requires A, when you require('B') then A will be loaded (added to sys.path, more technically). But if B is *not* installed --multi-version you can start using it without require()ing it, and A won't have been loaded. Given this, I feel like I need to do the basic require()s in my __init__.py. But, at least for some packages (like SQLObject) I want the package to be usable without setuptools. It gets complicated then, because you'd have to do: try: import pkg_resources try: pkg_resources.require(...) except pkg_resources.ResolutionError: # Who knows how everything may be installed, lets be # optimistic and wait for a later ImportError... pass except ImportError: pass At least, that's the best I've figured out.
At 03:11 PM 9/21/2005 -0500, Ian Bicking wrote:
I'm reading through the documentation some...
Regarding this:
Note, by the way, that if you declare your dependencies in setup.py, you do not need to use the require() function in your scripts or modules, as long as you either install the project or use setup.py develop to do development work on it. (See "Development Mode" below for more details on using setup.py develop.)
I don't think this is quite true. In particular, I've noticed if you install a package A --multi-version, it fulfills the requirement for A. And if you have a package B that requires A, when you require('B') then A will be loaded (added to sys.path, more technically). But if B is *not* installed --multi-version you can start using it without require()ing it, and A won't have been loaded.
What I was trying to say was that scripts installed by easy_install or "setup develop" do not require any require()s, as that is handled by the generated wrapper.
Given this, I feel like I need to do the basic require()s in my __init__.py.
I'm not positive that's true. If you install B without --multi-version, in principle it should de-multi-versionize A as well. (At least, that's what I'd expect it to do; I'm not 100% sure if it does. I know for sure it'll do it if "A" isn't installed when you install "B".) That doesn't mean you can't go back and re-MV-ize "A", but there are always ways for people to break things. A full package management tool layered over setuptools should take care of things like warning you that you're going to deactivate something needed by something else.
Phillip J. Eby wrote:
Regarding this:
Note, by the way, that if you declare your dependencies in setup.py, you do not need to use the require() function in your scripts or modules, as long as you either install the project or use setup.py develop to do development work on it. (See "Development Mode" below for more details on using setup.py develop.)
I don't think this is quite true. In particular, I've noticed if you install a package A --multi-version, it fulfills the requirement for A. And if you have a package B that requires A, when you require('B') then A will be loaded (added to sys.path, more technically). But if B is *not* installed --multi-version you can start using it without require()ing it, and A won't have been loaded.
What I was trying to say was that scripts installed by easy_install or "setup develop" do not require any require()s, as that is handled by the generated wrapper.
You also mention modules there.
Given this, I feel like I need to do the basic require()s in my __init__.py.
I'm not positive that's true. If you install B without --multi-version, in principle it should de-multi-versionize A as well. (At least, that's what I'd expect it to do; I'm not 100% sure if it does. I know for sure it'll do it if "A" isn't installed when you install "B".) That doesn't mean you can't go back and re-MV-ize "A", but there are always ways for people to break things.
Yes. But, I'm pretty sure I've done these things (though in retrospect it's hard to remember exactly what and in what order). In part it's because of my old sys.path ways. But I don't think it will be uncommon to get in these jams... so, there should be a clear way out. Not that the paragraph above will give a clear way no matter what it says... I think better error messages would probably be the best way to make this stuff easier. E.g., version conflict messages could include file paths. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org
participants (2)
-
Ian Bicking -
Phillip J. Eby