This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Unsupported provider

classification
Title: distutils[2] should recreate scripts in the build tree
Type: behavior Stage: resolved
Components: Distutils Versions: Python 3.4, Python 3.5
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: eric.araujo Nosy List: alexis, dstufft, eric.araujo, gjb1002, steve.dower, tarek
Priority: normal Keywords: easy

Created on 2010-11-09 13:11 by gjb1002, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (7)
msg120864 - (view) Author: Geoffrey Bache (gjb1002) Date: 2010-11-09 13:11
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.

The cached script in the build tree appears not to get updated once it exists.
msg120878 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2010-11-09 16:25
As described in distutils-SIG, we need to work on a clever way to update the build tree.

For Distutils1, removing it completely (possibly via the clean command) is what people can do.
msg121405 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-11-18 01:31
For this particular bug, we could add a check for the shebang line in distutils1’ build_scripts, so that a second run can detect it should rebuild the scripts even though the source has not changed.  Or is there a rule that says build_* command only look at timetamps to decide that?

I agree about the larger problem that cannot be solved entirely and nicely in distutils2.
msg156966 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-03-28 04:22
I now think that this should be fixed in d1 too.  We could just always rebuild scripts (it’s just a file copy), or implement the matching idea from my previous message.

To answer my own question:
> Or is there a rule that says build_* command only look at timetamps to decide that?
I think a command is free to do whatever inspection it needs to determine is something needs rebuilding.

Tests would need to exercise both the --executable option of build_scripts and default value.  Thankfully the code uses sys.executable and we can inject a custom value in a test.  Adding the easy keyword, I think this is a good candidate for the upcoming Montreal sprint.
msg160898 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-05-16 17:57
In distutils2, 99382aafa4c5 forces scripts to always be rebuilt and 463d3014ee4a goes further and deletes the whole build dir to avoid installing scripts built from a previous build call with a different configuration (i.e. different list of scripts).

The same issue may affect other build commands; if a module is built and then removed from the source dir and setup.cfg/.py, I think the install command would still install it.  The dependency code should take setup.cfg and files referenced from hooks to decide if the source is newer, and it should delete built files for which there is no source.
msg222407 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-07-06 15:14
I always find distutils anything but easy :)
msg386303 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2021-02-03 18:16
Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.

If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools
History
Date User Action Args
2022-04-11 14:57:08adminsetgithub: 54583
2021-02-03 18:16:21steve.dowersetstatus: open -> closed

nosy: + steve.dower
messages: + msg386303

resolution: out of date
stage: test needed -> resolved
2019-03-16 00:15:29BreamoreBoysetnosy: - BreamoreBoy
2014-07-06 15:14:02BreamoreBoysetversions: + Python 3.4, Python 3.5, - 3rd party, Python 2.7, Python 3.2, Python 3.3
nosy: + BreamoreBoy, dstufft

messages: + msg222407

components: - Distutils2
2012-05-16 17:57:13eric.araujosetmessages: + msg160898
2012-03-28 04:24:16eric.araujolinkissue14357 superseder
2012-03-28 04:22:20eric.araujoset
assignee: tarek -> eric.araujo
keywords: + easy
stage: test needed
title: setup.py caches outdated scripts in the build tree -> distutils[2] should recreate scripts in the build tree
nosy: + alexis
versions: + Python 2.7, Python 3.2, Python 3.3
messages: + msg156966
components: + Distutils
type: enhancement -> behavior
2010-11-18 01:31:51eric.araujosetmessages: + msg121405
versions: + 3rd party, - Python 2.6
2010-11-09 16:25:29tareksettype: behavior -> enhancement
messages: + msg120878
components: + Distutils2, - Distutils
2010-11-09 13:11:28gjb1002create