On Wed, 20 May 2009 12:37:19 +0100, "A. Cavallo" <a.cavallo@cavallinux.eu> wrote:
Or my preferred way: $cat foobar/__init__.py __version__ = "0.9.33"
and import foobar should not trigger code execution anyway IMHO so $ python -c 'import foobar; print foobar.__version__' 0.9.33
That doesn't work in all cases.
No it is not that the case and I'm going to bore you probably (sorry).
[snip - explanation of how you can import from the package you're about to install]
This is true, but it is not the complete story. You explained the case where setup.py is being run directly to install the package. My first post in the thread explained that this case works fine. It's other cases, such as easy_install and buildout which do not work with this strategy. (Someone who has experience with these tools might be able to explain why this is; I haven't investigated the details yet, I only know that people are reporting bugs against my packages.)
[snip]
Then we need to agree on what do we mean for install and packaging.... "python setup.py install", "python setup.py bdist_rpm/wininst" or during a complete deb/rpm package build? In the latter the version the "version" is the one available in the spec/deb files and it cannot be reflected from the sources anyway, no matter how hard one try to do it.
The only version I'm talking about here is the one I assign to my package. If someone else is assigning a different version, then it becomes their problem to make things work.
[snip]
Finding modules can always be forced using PYTHONPATH (like in case of foobar-1.0/src/foobar layout) or from setup.py inserting into sys.path the subdir: that's the easiest and in my opinion the best way to do it during build/install stages.
Maybe so, but it can be made compatible with all (or most, or any?) of the tools people are using to install distutils-based packages these days? Jean-Paul