| msg81749 - (view) |
Author: Ned Deily (ned.deily) *  |
Date: 2009-02-12 12:05 |
| An instance of the shell script "Update Shell Profile.command" is installed in each "/Applications/Python x.x" folder. Clicking on the script allows the user to change the default Python version. If the scripts are run more than once - say first to make 3.0 the default then 2.6 the default then back to 3.0 again - the script will fail to update the user's PATH,forcinguserstomanuallyedittheirshellprofile.SOLUTIONEnsurethatPATH, forcing users to manually edit their shell profile. SOLUTION Ensure that PATH,forcinguserstomanuallyedittheirshellprofile.SOLUTIONEnsurethatPATH is updated if there are other Python frameworks already on its head. (This is not the most elegant solution since it leaves the previous versions later in the path but it is safer to only append to the user's profile - and a backup copy is made.) APPLIES py3k, 3.0, trunk, 2.6 |
|
|
| msg81772 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2009-02-12 15:22 |
| I don't like this patch because it could grow the users profile without bounds when switching back and forth between two python versions. |
|
|
| msg81813 - (view) |
Author: Ned Deily (ned.deily) * |
Date: 2009-02-12 20:01 |
| I agree the patch is not a good solution but it is relatively safe. I suppose the current buggy behavior of Update Shell Profile *does* limit the growth to the number of Python versions you've installed. However the patch does allow users not comfortable with shell scripts to move between versions. On the other hand, they can always use the various IDLEs. This whole area of PATH manipulation and symlinks for OS X could use a good re- thinking; a lot of cruft has accumulated over the years and it gets worse with 4-way builds. |
|
|
| msg81830 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2009-02-12 22:33 |
| I agree that we need a better solution to select which version of Python is the default one of your path. One way to do that is to have a tool that can change the "Current" link inside the framework, that way we could have /Library/Frameworks/Python.framework/Version/Current/bin early on $PATH and add the various version directories after that. I'd also like to see a per-user way to change the default python without manually editing the shell profile. W.r.t. to the myriad of other variations in a 4-way universal build: those are necessary to ensure that you can easily force the use of a 32- bit or 64-bit build because at the time a lot of GUI code required 32- bit code. I hope this will change over time, I'd love to have a much simpler framework that contains only a single copy of the python executable instead of the 3 variants that are currently present in a 4- way universal build. |
|
|
| msg269105 - (view) |
Author: Carol Willing (willingc) * |
Date: 2016-06-23 04:53 |
| Closed as an out of date issue. |
|
|
| msg269171 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2016-06-24 13:59 |
| Why is it out of date? Did Ned solve this another way at some point? What I'm getting at is just closing an issue as "out of date" is not enough, really, it is best to record *why* the issue is out of date. |
|
|
| msg269173 - (view) |
Author: Carol Willing (willingc) * |
Date: 2016-06-24 14:07 |
| This issue was closed as "out of date" since there has been no activity on the issue in 7 years. IMHO the issue, if still relevant, should be opened as a new issue with better scope based on today's technology. |
|
|
| msg269175 - (view) |
Author: Carol Willing (willingc) * |
Date: 2016-06-24 14:10 |
| Perhaps it would be prudent to update the dev guide, or the contribution process, to close issues that have stagnated for years as opposed to marking them languishing. It would likely help with the issue backlog. Also, expanding out of date to reflect that an issue has not been touched in over 'x' years would be helpful too. Perhaps that should be an addition to the dev guide. |
|
|
| msg269187 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2016-06-24 15:04 |
| I don't think "out of date" means "hasn't been touched in X years", I think it means "there is no longer any need to fix this issue". That might mean it is a bug in something we no longer support, or a bug that has been fixed accidentally by later development. |
|
|
| msg344871 - (view) |
Author: Carol Willing (willingc) * |
Date: 2019-06-06 20:28 |
| @ned.deily I'm doing some triaging today. As the original submitter of this issue, would you be willing to close it? Thanks. |
|
|
| msg344876 - (view) |
Author: Ned Deily (ned.deily) * |
Date: 2019-06-06 21:03 |
| Please don’t close this. It’s still an issue that needs to be addressed and I intend to do so. Thanks. |
|
|
| msg344877 - (view) |
Author: Carol Willing (willingc) * |
Date: 2019-06-06 21:06 |
| No problem :D Ping me when you need a review. |
|
|