setup.py script using python interpreter from previous run
Hi all, I have the following setup.py script: #!/usr/bin/env python from distutils.core import setup scripts=["hello.py"] setup(scripts=scripts) I have two different python installations (using virtualenv) where I wish to install this program. So I do ~/tmp/test_setup/python1/bin/python setup.py install which creates a file at /users/geoff/tmp/test_setup/python1/bin/hello.py, that looks like this: #!/users/geoff/tmp/test_setup/python1/bin/python print "Hello" So far so good. But then I also install it somewhere else: ~/tmp/test_setup/python2/bin/python setup.py install which creates a file at /users/geoff/tmp/test_setup/python2/bin/hello.py which refers to "python1", i..e it has the same contents as the first one. Which is clearly not what I want. Is this a bug? Or have I missed something in my setup.py? It works of course if I remove the generated "build" directory by hand, but it's not so nice to have to remember to do that. (I'm using Python2.6 on Linux) Regards, Geoff Bache
On Tue, Nov 9, 2010 at 5:58 AM, Geoff Bache <geoff.bache@gmail.com> wrote:
Is this a bug?
I think so.
Or have I missed something in my setup.py? It works of course if I remove the generated "build" directory by hand, but it's not so nice to have to remember to do that.
You should be able to remove the build/ directory that was created where the package is unpacked, and then run the install command with your python2/bin/python. The problem is that "build" and "install" are traditionally two distinct steps. While setup.py takes care of both for you, it does detect that you switched Python's, so doesn't re-build for the second. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> "A storm broke loose in my mind." --Albert Einstein
On Tue, Nov 9, 2010 at 12:04 PM, Fred Drake <fdrake@acm.org> wrote:
On Tue, Nov 9, 2010 at 5:58 AM, Geoff Bache <geoff.bache@gmail.com> wrote:
Is this a bug?
I think so.
Or have I missed something in my setup.py? It works of course if I remove the generated "build" directory by hand, but it's not so nice to have to remember to do that.
You should be able to remove the build/ directory that was created where the package is unpacked, and then run the install command with your python2/bin/python. The problem is that "build" and "install" are traditionally two distinct steps. While setup.py takes care of both for you, it does detect that you switched Python's, so doesn't re-build for the second.
Since we're adding the "configure" command that will let install have an access to all build options that were used, (still in Eric's branch) we should be able to know where the script is in the build tree, and check in install_scripts that its not outdated with the file timestamps + checking the shebang line. Or... keep in that configure file the path to the interpreter and just rebuild all scripts in case the interpreter has changed.
-Fred
-- Fred L. Drake, Jr. <fdrake at acm.org> "A storm broke loose in my mind." --Albert Einstein _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Tarek Ziadé | http://ziade.org
On Tue, Nov 9, 2010 at 6:31 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
Or... keep in that configure file the path to the interpreter and just rebuild all scripts in case the interpreter has changed.
+1 to the simple approach. Given the need to do this, I guess I don't really see the value of storing scripts in the build tree. But I suppose someone actually uses them from there somehow. (I'd expect getting the imports to work would be a painful exercise, but I've seen enough tortured processes that I wouldn't put it past folks.) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> "A storm broke loose in my mind." --Albert Einstein
2010/11/9 Tarek Ziadé <ziade.tarek@gmail.com>:
Since we're adding the "configure" command that will let install have an access to all build options that were used, (still in Eric's branch) we should be able to know where the script is in the build tree, and check in install_scripts that its not outdated with the file timestamps + checking the shebang line.
Or... keep in that configure file the path to the interpreter and just rebuild all scripts in case the interpreter has changed.
In my opinion it might be worthy storing some combination (interpreter path, interpreter build no). Case study: For building some binaries, we are using both py2.7-macosx10.3 and py2.7-macosx10.5 on Mac OS X (obviously), which are different builds but must be installed to exactly the same default location (some technicalities). Of course only one of them is installed at a time. We just recently ran into an error (failure) where we think we used py2.7-10.3 built binaries to make a py2.7-10.5 installer (or vice versa). This came so because the build directory was reused. A solution might be to include the build number or something similar in the build/anything-something directory name. Maybe just add a hash of the tuple (installer path, build no) in the build directory's name? Obviously, then both interpreter path change as well as interpreter build number change would lead to another build directory. Might be useful to be able to use different Pythons in parallel for parallel builds. One could add whatever is needed later to the hashed tuple without breaking compatibility. (E.g., build options :-) Friedrich
On Tue, Nov 9, 2010 at 11:58 AM, Geoff Bache <geoff.bache@gmail.com> wrote:
Hi all,
I have the following setup.py script:
#!/usr/bin/env python from distutils.core import setup
scripts=["hello.py"]
setup(scripts=scripts)
I have two different python installations (using virtualenv) where I wish to install this program. So I do
~/tmp/test_setup/python1/bin/python setup.py install
which creates a file at /users/geoff/tmp/test_setup/python1/bin/hello.py, that looks like this:
#!/users/geoff/tmp/test_setup/python1/bin/python
print "Hello"
So far so good. But then I also install it somewhere else:
~/tmp/test_setup/python2/bin/python setup.py install
which creates a file at /users/geoff/tmp/test_setup/python2/bin/hello.py which refers to "python1", i..e it has the same contents as the first one. Which is clearly not what I want.
Is this a bug? Or have I missed something in my setup.py? It works of course if I remove the generated "build" directory by hand, but it's not so nice to have to remember to do that.
Can you add an issue in bugs.python.org please (using the "Distutils2" component and "feature request") This is a general problem we have in Distutils: update an existing build if some of its elements are out of date. We need to add some kind of replacement mechanism (not sure how yet). This won't be fixed in Distutils 1, but we can change the behavior in Distutils2. In the meantime, you should remove the build directory by hand or use the "clean" command that does it for you in your call: ~/tmp/test_setup/python2/bin/python setup.py clean -a install Sorry for the inconveniency
(I'm using Python2.6 on Linux)
Regards, Geoff Bache _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Tarek Ziadé | http://ziade.org
Hi Tarek,
Can you add an issue in bugs.python.org please (using the "Distutils2" component and "feature request")
I've added a bug, but felt I had to describe it as I saw it (i.e. a behaviour issue with Distutils). It took me quite some time to track down what was going on, and I didn't think I was doing anything complicated or unusual. It can't be that hard to fix it in distutils can it (as you've just been discussing)? Regards, Geoff
participants (4)
-
Fred Drake -
Friedrich Romstedt -
Geoff Bache -
Tarek Ziadé