`develop' doesn't appends my package's directory to sys.path
Hello, everyone. I have an script which is supposed to run my test suite periodically, and the routine is basically this: 1.- It checkouts my app's source from the repository, and stores it in a different directory on every checkout. 2.- It runs setuptools build. 3.- It runs setuptools develop. 4.- It runs my test suite (via setuptools unittest). But setuptools' develop doesn't append my project's path to sys.path; I don't know what is going on, but I'm absolutely sure about that. Here is part of the verbose output of the script (it's actually not an script per se; I'm using an Ant like app, part of the Bitten continuous integration system):
[DEBUG ] Executing <function exec_ at 0x83ccdf4> with arguments: {'executable': './setup.py', 'args': 'develop'} [DEBUG ] Executing ['./setup.py', 'develop']
And because my package is not accessible, its modules are not accessible either:
ImportError: No module named build.lib.animador.config
Then, from the Python interpreter, I check sys.path and I find that my package's path is not included. But if I manually run `setup.py develop', and then open the Python interpreter again, the path is included. Here's the output of my script http://paste.turbogears.org/paste/3255 and here's the full output of `setup.py develop' http://paste.turbogears.org/paste/3256 Also, here's my repository https://svn.gnulinuxmatters.org:81/animador/trunk/ and here you can browse the source code: https://tracker.gnulinuxmatters.org/browser/animador/trunk I hope someone can help me out; I have spent days trying to fix this. Thanks in advance. -- Gustavo Narea. General Secretary. GNU/Linux Matters. http://www.gnulinuxmatters.org/
I would suggest setting DISTUTILS_DEBUG=yes in your environment when running both, and compare the other environment contents. My guess is that you are either running a different Python executable or have a different HOME -- which might change what setup.cfg is being used, and thus the target install directory. Notice in particular that the run for your wrapper script says that it is already present in easy-install.pth, while the other run does not. This suggests that the target installation path is different. Personally, however, I don't see the point of your script running "build" or "develop" prior to "test"; running "test" will both do a build and put the package on sys.path for the duration of the test run, so the preceding commands are redundant. Also, if for some reason you *did* need to run all three in sequence, you could just do "setup.py build develop test" and save a lot of excess overhead and repetition. At 10:07 PM 7/18/2008 +0200, Gustavo Narea wrote:
Hello, everyone.
I have an script which is supposed to run my test suite periodically, and the routine is basically this: 1.- It checkouts my app's source from the repository, and stores it in a different directory on every checkout. 2.- It runs setuptools build. 3.- It runs setuptools develop. 4.- It runs my test suite (via setuptools unittest).
But setuptools' develop doesn't append my project's path to sys.path; I don't know what is going on, but I'm absolutely sure about that. Here is part of the verbose output of the script (it's actually not an script per se; I'm using an Ant like app, part of the Bitten continuous integration system):
[DEBUG ] Executing <function exec_ at 0x83ccdf4> with arguments: {'executable': './setup.py', 'args': 'develop'} [DEBUG ] Executing ['./setup.py', 'develop']
And because my package is not accessible, its modules are not accessible either:
ImportError: No module named build.lib.animador.config
Then, from the Python interpreter, I check sys.path and I find that my package's path is not included. But if I manually run `setup.py develop', and then open the Python interpreter again, the path is included.
Here's the output of my script http://paste.turbogears.org/paste/3255 and here's the full output of `setup.py develop' http://paste.turbogears.org/paste/3256
Also, here's my repository https://svn.gnulinuxmatters.org:81/animador/trunk/ and here you can browse the source code: https://tracker.gnulinuxmatters.org/browser/animador/trunk
I hope someone can help me out; I have spent days trying to fix this.
Thanks in advance. -- Gustavo Narea. General Secretary. GNU/Linux Matters. http://www.gnulinuxmatters.org/
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Hi, everyone, I've been in the process of rebuilding my robot, W.A.L.T.E.R. and will be using Python to create all the new control and interface software for it. I'm currently using Gentoo Embedded Linux on a TinCanTools Hammer Board (http://www.tincantools.com). I have gotten all the software components I need cross compiled except two - pysqlite and imaging (Python Imaging). These packages have extensions, and will not cross compile properly. I'm willing to do work on getting a cross compile working for these types of packages, but am not quite sure where to start. I've been looking at the code for distutils that installes with Python 2.4.4, and I think I understand at least part of what needs to be done, but again am not completely sure because I don't know how to interface to distutils. What is the proper way to interface to distutils to start a build? Is there already a mechanism to tell distutils which compiler to use and/or which platform to build for? 8-Dale
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dale Weber wrote:
Hi, everyone,
I've been in the process of rebuilding my robot, W.A.L.T.E.R. and will be using Python to create all the new control and interface software for it. I'm currently using Gentoo Embedded Linux on a TinCanTools Hammer Board (http://www.tincantools.com). I have gotten all the software components I need cross compiled except two - pysqlite and imaging (Python Imaging). These packages have extensions, and will not cross compile properly.
I'm willing to do work on getting a cross compile working for these types of packages, but am not quite sure where to start. I've been looking at the code for distutils that installes with Python 2.4.4, and I think I understand at least part of what needs to be done, but again am not completely sure because I don't know how to interface to distutils.
What is the proper way to interface to distutils to start a build? Is there already a mechanism to tell distutils which compiler to use and/or which platform to build for?
You can run the 'build_ext' step separately, which allows you to specify several options you may need:: - ----------------------- 8< ---------------------------------- $ python setup.py build_ext --help Global options: --verbose (-v) run verbosely (default) --quiet (-q) run quietly (turns verbosity off) --dry-run (-n) don't actually do anything --help (-h) show detailed help message Options for 'build_ext' command: --build-lib (-b) directory for compiled extension modules --build-temp (-t) directory for temporary files (build by-products) --inplace (-i) ignore build-lib and put compiled extensions into the source directory alongside your pure Python modules --include-dirs (-I) list of directories to search for header files (separated by ':') --define (-D) C preprocessor macros to define --undef (-U) C preprocessor macros to undefine --libraries (-l) external C libraries to link with --library-dirs (-L) directories to search for external C libraries (separated by ':') --rpath (-R) directories to search for shared C libraries at runtime --link-objects (-O) extra explicit link objects to include in the link --debug (-g) compile/link with debugging information --force (-f) forcibly build everything (ignore file timestamps) --compiler (-c) specify the compiler type --swig-cpp make SWIG create C++ files (default is C) --swig-opts list of SWIG command line options --swig path to the SWIG executable --help-compiler list available compilers usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help $ python setup.py build_ext --help-compiler List of available compilers: --compiler=bcpp Borland C++ Compiler --compiler=cygwin Cygwin port of GNU C Compiler for Win32 --compiler=emx EMX port of GNU C Compiler for OS/2 --compiler=mingw32 Mingw32 port of GNU C Compiler for Win32 --compiler=msvc Microsoft Visual C++ --compiler=mwerks MetroWerks CodeWarrior --compiler=unix standard UNIX-style compiler - ----------------------- 8< ---------------------------------- Hope that helps, Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIgjTc+gerLs4ltQ4RAjjQAKC1+gANXAHX41mPUgYF1FLKIgi5ggCglo7v UWDXEmNG0/ezLflE1q+hSEE= =volI -----END PGP SIGNATURE-----
Hello, Phillip. I don't really understand why, but if I don't run "build" my script works. However I need "develop" because the Ant-like tool runs my test suite on a different folder for every svn revision. If I remove "build", I get an import error because my modules are not accessible. Thanks for your help! Cheers. On Saturday 19 July 2008 00:27:02 Phillip J. Eby wrote:
I would suggest setting DISTUTILS_DEBUG=yes in your environment when running both, and compare the other environment contents. My guess is that you are either running a different Python executable or have a different HOME -- which might change what setup.cfg is being used, and thus the target install directory.
Notice in particular that the run for your wrapper script says that it is already present in easy-install.pth, while the other run does not. This suggests that the target installation path is different.
Personally, however, I don't see the point of your script running "build" or "develop" prior to "test"; running "test" will both do a build and put the package on sys.path for the duration of the test run, so the preceding commands are redundant. Also, if for some reason you *did* need to run all three in sequence, you could just do "setup.py build develop test" and save a lot of excess overhead and repetition.
At 10:07 PM 7/18/2008 +0200, Gustavo Narea wrote:
Hello, everyone.
I have an script which is supposed to run my test suite periodically, and the routine is basically this: 1.- It checkouts my app's source from the repository, and stores it in a different directory on every checkout. 2.- It runs setuptools build. 3.- It runs setuptools develop. 4.- It runs my test suite (via setuptools unittest).
But setuptools' develop doesn't append my project's path to sys.path; I don't know what is going on, but I'm absolutely sure about that. Here is part of the verbose output of the script (it's actually not an script per se; I'm
using an Ant like app, part of the Bitten continuous integration system):
[DEBUG ] Executing <function exec_ at 0x83ccdf4> with arguments: {'executable': './setup.py', 'args': 'develop'} [DEBUG ] Executing ['./setup.py', 'develop']
And because my package is not accessible, its modules are not accessible
either:
ImportError: No module named build.lib.animador.config
Then, from the Python interpreter, I check sys.path and I find that my package's path is not included. But if I manually run `setup.py develop', and then open the Python interpreter again, the path is included.
Here's the output of my script http://paste.turbogears.org/paste/3255 and here's the full output of `setup.py develop' http://paste.turbogears.org/paste/3256
Also, here's my repository https://svn.gnulinuxmatters.org:81/animador/trunk/ and here you can browse the source code: https://tracker.gnulinuxmatters.org/browser/animador/trunk
I hope someone can help me out; I have spent days trying to fix this.
Thanks in advance. -- Gustavo Narea. General Secretary. GNU/Linux Matters. http://www.gnulinuxmatters.org/
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Gustavo Narea. General Secretary. GNU/Linux Matters. http://www.gnulinuxmatters.org/
It doesn't sound like you read what I wrote below, or that you did any of what I said to do, so I'm not sure what other help I can offer. (Also, your statements about "develop" and "build" are mutually inconsistent.) At 07:32 PM 7/19/2008 +0200, Gustavo Narea wrote:
Hello, Phillip.
I don't really understand why, but if I don't run "build" my script works.
However I need "develop" because the Ant-like tool runs my test suite on a different folder for every svn revision. If I remove "build", I get an import error because my modules are not accessible.
Thanks for your help!
Cheers.
On Saturday 19 July 2008 00:27:02 Phillip J. Eby wrote:
I would suggest setting DISTUTILS_DEBUG=yes in your environment when running both, and compare the other environment contents. My guess is that you are either running a different Python executable or have a different HOME -- which might change what setup.cfg is being used, and thus the target install directory.
Notice in particular that the run for your wrapper script says that it is already present in easy-install.pth, while the other run does not. This suggests that the target installation path is different.
Personally, however, I don't see the point of your script running "build" or "develop" prior to "test"; running "test" will both do a build and put the package on sys.path for the duration of the test run, so the preceding commands are redundant. Also, if for some reason you *did* need to run all three in sequence, you could just do "setup.py build develop test" and save a lot of excess overhead and repetition.
At 10:07 PM 7/18/2008 +0200, Gustavo Narea wrote:
Hello, everyone.
I have an script which is supposed to run my test suite periodically, and the routine is basically this: 1.- It checkouts my app's source from the repository, and stores it in a different directory on every checkout. 2.- It runs setuptools build. 3.- It runs setuptools develop. 4.- It runs my test suite (via setuptools unittest).
But setuptools' develop doesn't append my project's path to sys.path; I don't know what is going on, but I'm absolutely sure about that. Here is part of the verbose output of the script (it's actually not an script per se; I'm
using an Ant like app, part of the Bitten continuous integration system):
[DEBUG ] Executing <function exec_ at 0x83ccdf4> with arguments: {'executable': './setup.py', 'args': 'develop'} [DEBUG ] Executing ['./setup.py', 'develop']
And because my package is not accessible, its modules are not accessible
either:
ImportError: No module named build.lib.animador.config
Then, from the Python interpreter, I check sys.path and I find that my package's path is not included. But if I manually run `setup.py develop', and then open the Python interpreter again, the path is included.
Here's the output of my script http://paste.turbogears.org/paste/3255 and here's the full output of `setup.py develop' http://paste.turbogears.org/paste/3256
Also, here's my repository https://svn.gnulinuxmatters.org:81/animador/trunk/ and here you can browse the source code: https://tracker.gnulinuxmatters.org/browser/animador/trunk
I hope someone can help me out; I have spent days trying to fix this.
Thanks in advance. -- Gustavo Narea. General Secretary. GNU/Linux Matters. http://www.gnulinuxmatters.org/
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Gustavo Narea. General Secretary. GNU/Linux Matters. http://www.gnulinuxmatters.org/
Hello, Phillip. On Saturday 19 July 2008 20:35:54 Phillip J. Eby wrote:
It doesn't sound like you read what I wrote below, or that you did any of what I said to do, so I'm not sure what other help I can offer.
I did do what you said, and sorry for not letting you know about the result I got. The output is basically the same; the environment contents are exactly the same (which you can verify, because the output is attached). The only thing that changes is that with the build system I get
Animador 1.0a1 is already the active version in easy-install.pth while with `setup.py develop' I get Adding Animador 1.0a1 to easy-install.pth file
But that's the only difference. I found that if I remove "build", the test suite finally works, and therefore I didn't try to understand what's the problem with setuptools' develop in my script if the environment contents are the same as in `setup.py develop'.
(Also, your statements about "develop" and "build" are mutually inconsistent.)
I don't understand why you think that. Setuptools' build is included in the only example of configuration file for a Python-powered project I found in the documentation of the continuous integration system I use, Bitten, so I thought it was required and therefore I included it in my script. But when I noticed it breaks the script, I removed it. Regarding "develop", I had to include it in my script because otherwise my packages' modules wouldn't be accessible - I got import errors when I didn't use it. Thank you very much for your help. Cheers, - Gustavo.
At 07:32 PM 7/19/2008 +0200, Gustavo Narea wrote:
Hello, Phillip.
I don't really understand why, but if I don't run "build" my script works.
However I need "develop" because the Ant-like tool runs my test suite on a different folder for every svn revision. If I remove "build", I get an import error because my modules are not accessible.
Thanks for your help!
Cheers.
On Saturday 19 July 2008 00:27:02 Phillip J. Eby wrote:
I would suggest setting DISTUTILS_DEBUG=yes in your environment when running both, and compare the other environment contents. My guess is that you are either running a different Python executable or have a different HOME -- which might change what setup.cfg is being used, and thus the target install directory.
Notice in particular that the run for your wrapper script says that it is alrady present in easy-install.pth, while the other run does not. This suggests that the target installation path is different.
Personally, however, I don't see the point of your script running "build" or "develop" prior to "test"; running "test" will both do a build and put the package on sys.path for the duration of the test run, so the preceding commands are redundant. Also, if for some reason you *did* need to run all three in sequence, you could just do "setup.py build develop test" and save a lot of excess overhead and repetition.
At 10:07 PM 7/18/2008 +0200, Gustavo Narea wrote:
Hello, everyone.
I have an script which is supposed to run my test suite periodically, and the routine is basically this: 1.- It checkouts my app's source from the repository, and stores it in a different directory on every checkout. 2.- It runs setuptools build. 3.- It runs setuptools develop. 4.- It runs my test suite (via setuptools unittest).
But setuptools' develop doesn't append my project's path to sys.path; I don't know what is going on, but I'm absolutely sure about that. Here is part of the verbose output of the script (it's actually not an script per se; I'm
using an Ant like app, part of the Bitten continuous integration system):
[DEBUG ] Executing <function exec_ at 0x83ccdf4> with arguments: {'executable': './setup.py', 'args': 'develop'} [DEBUG ] Executing ['./setup.py', 'develop']
And because my package is not accessible, its modules are not accessible
either:
ImportError: No module named build.lib.animador.config
Then, from the Python interpreter, I check sys.path and I find that my package's path is not included. But if I manually run `setup.py develop', and then open the Python interpreter again, the path is included.
Here's the output of my script http://paste.turbogears.org/paste/3255 and here's the full output of `setup.py develop' http://paste.turbogears.org/paste/3256
Also, here's my repository https://svn.gnulinuxmatters.org:81/animador/trunk/ and here you can browse the source code: https://tracker.gnulinuxmatters.org/browser/animador/trunk
I hope someone can help me out; I have spent days trying to fix this.
Thanks in advance. -- Gustavo Narea. General Secretary. GNU/Linux Matters. http://www.gnulinuxmatters.org/
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Gustavo Narea. General Secretary. GNU/Linux Matters. http://www.gnulinuxmatters.org/
-- Gustavo Narea. General Secretary. GNU/Linux Matters. http://www.gnulinuxmatters.org/
At 02:34 PM 7/20/2008 +0200, Gustavo Narea wrote:
Hello, Phillip.
On Saturday 19 July 2008 20:35:54 Phillip J. Eby wrote:
It doesn't sound like you read what I wrote below, or that you did any of what I said to do, so I'm not sure what other help I can offer.
I did do what you said, and sorry for not letting you know about the result I got.
The output is basically the same; the environment contents are exactly the same (which you can verify, because the output is attached). The only thing that changes is that with the build system I get
Animador 1.0a1 is already the active version in easy-install.pth while with `setup.py develop' I get Adding Animador 1.0a1 to easy-install.pth file
I think you should probably dump the contents of your easy-install.pth file before and after running each one, so we can see what's happening there, exactly.
But that's the only difference.
I found that if I remove "build", the test suite finally works, and therefore I didn't try to understand what's the problem with setuptools' develop in my script if the environment contents are the same as in `setup.py develop'.
(Also, your statements about "develop" and "build" are mutually inconsistent.)
I don't understand why you think that.
You said: """If I don't run "build" my script works. However I need "develop" because the Ant-like tool runs my test suite on a different folder for every svn revision. If I remove "build", I get an import error because my modules are not accessible.""" In other words, you said that you need develop because if you don't use build you get an error. But also that if you remove build it works. So, your statements are not such that I can make any kind of consistent sense of what is happening. Also, "build" should have zero effect on testing or installing, and "develop" should be unnecessary for testing, regardless of what directory your code is unpacked in. You should simply be able to run "setup.py test" and skip all this build and develop stuff, because the "test" command puts the code on sys.path while the tests are running, and it also executes any build steps that are necessary.
Regarding "develop", I had to include it in my script because otherwise my packages' modules wouldn't be accessible - I got import errors when I didn't use it.
What import errors, specifically?
participants (4)
-
Dale Weber -
Gustavo Narea -
Phillip J. Eby -
Tres Seaver