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.

Author vinay.sajip
Recipients alexis, ceder, eric.araujo, fdrake, higery, mhammond, tarek, tim.golden, vinay.sajip
Date 2011-08-18.15:56:52
SpamBayes Score 1.9308322e-08
Marked as misclassified No
Message-id <1313683011.68691.YahooMailNeo@web25808.mail.ukl.yahoo.com>
In-reply-to
Content
>________________________________
>NO. I removed the 'copy_scripts' function, so I did not use your developed functionality. After this change, Packaging module now just builds new-style scripts and old-style scripts will be built by distutils/setuptools. To support the old-style scripts generated by d*/s* in p*, we can use the resource system.
>
>Not just as is, I believe. When scripts are installed (as opposed to other resources), it's not enough to copy them across to the configured destination: you also need to change their shebang lines to point to the appropriate Python executable. This is particularly important in virtualenvs where there could be any number of Python executables (of different versions) represented. But how will we know which .py files mentioned in resources are data, and which are actually scripts?

To me, it actually makes more sense to keep those scripts in the [scripts] section, and have some way of recognising which scripts need to be copied/amended and which ones need to be generated from callables.
Files
File name Uploaded
unnamed vinay.sajip, 2011-08-18.15:56:52
History
Date User Action Args
2011-08-18 15:56:53vinay.sajipsetrecipients: + vinay.sajip, mhammond, fdrake, ceder, tim.golden, tarek, eric.araujo, alexis, higery
2011-08-18 15:56:52vinay.sajiplinkissue12394 messages
2011-08-18 15:56:52vinay.sajipcreate