Bugs item #1545658, was opened at 2006-08-24 02:27 Message generated for change (Comment added) made by movement You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). ---------------------------------------------------------------------- >Comment By: John Levon (movement) Date: 2006-09-11 20:24 Message: Logged In: YES user_id=53034 Regarding the first part of your reply - I can understand that; thanks for the detailed rationale. Perhaps this bug is really about the distutils docs? In particular it seems useful to clarify the problems with non-pure modules as well. Regarding the second - it's only relevant due to the lack of upstream vendor-packages support. That is, I was trying to clean up our builds to not have to do: mv site-packages vendor-packages (You can refer to the original vendor-packages discussion if you're still asking why we don't install into the main Python directory.) I understand this was more of a hack than a solution, so consider that part void. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2006-09-11 19:48 Message: Logged In: YES user_id=21627 It's ok for the Lib directory to be the same across Python versions because it means that the user doesn't have to reinstall the packages (atleast not the pure-python ones, and, conditionally, perhaps not even the binary ones) when the Python version changes. Python will automatically, transparently replace the byte code files when the system Python is updated, and the user only has to add a single directory to the PYTHONPATH. If the user has the convention to include ~/bin in his path, he doesn't need any additional setup for scripts that get installed. So, adding a version number into the directories would add additional inconvenience, since the user would have to install the same package multiple times, and because she would have to set PYTHONPATH differently depending on what Python version she wants to use. It is the way it is to please the user; changing it the way you propose would make it more inconvenient. Now, you suggest that the home scheme would be used by an OS vendor who likes to install into /usr/lib/python2.x. This is an abuse of the home scheme, and what works very well for a user apparently does not work well for an OS vendor. If the OS vendor tries this abuse anyway, he must live with the consequences. The user would be better advised to use the UNIX scheme, pass --prefix=/usr. This would automatically put things into /usr/lib/python2.x. Why the OS vendor would chose not do so, I cannot guess. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-11 10:17 Message: Logged In: YES user_id=53034 You still haven't given an explanation for why it's OK for it to be different just because it's in somebody's $HOME. > you have to live with the consequences Huh? This makes no sense. I'm filing a bug saying the home behaviour has problems and your answer is "it's not a bug, because if you use this option, then you must live with this bug". I can see an argument for this being an RFE, I suppose, but I've really lost interest now. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 21:08 Message: Logged In: YES user_id=21627 I read the example you gave. In case of a shared directory, you shouldn't use the "home" scheme. If you do anyway, you have to live with the consequences. The home scheme is called "home scheme" for a reason: the target directory is expected to be inside the user's home directory. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 20:12 Message: Logged In: YES user_id=53034 > not have the right to install Did you actually read the example I gave? Just because it's a "possible slowdown" doesn't mean that this behaviour is both inconsistent and potentially troublesome. But I suppose you don't care. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 19:00 Message: Logged In: YES user_id=21627 Why would a user not have the right to install to its own home directory? That's what the home scheme is there for. In any case, it seems that there won't be actual breakage, only a possible slowdown. I very much doubt that the slowdown would ever be significant, though. It seems you want to use the home scheme for something that it was not designed for. Notice that it is merely an abbreviation - you can specify the directories directly if you want to. I'm closing this as invalid: the original report ("Thus, breakage can occur.") is apparently wrong. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 18:51 Message: Logged In: YES user_id=53034 Consider a shared tree where users do not have access to write new .pyc's. Just like the standard python libraries, there could be a significant speed slowdown due to not being able to use the old .pyc's. It's the exact same case that prompts distro's to install into /usr/lib/pythonX.X/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 15:26 Message: Logged In: YES user_id=21627 It's true that the format of marshal may change. More regularly, the format of .pyc files may change due to changes in the byte codes. Yet, I fail to see why this can cause breakage. The pyc format is deliberately so designed that nothing will break even if the format changes. I'm still waiting for a demonstrable problem. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 14:55 Message: Logged In: YES user_id=53034 http://www.python.org/doc/1.5.2p2/lib/module-marshal.html specifically: "Details of the format are undocumented on purpose; it may change between Python versions (although it rarely does)." Thus, anyone using the home scheme can hit these changes as the format is not architecturally guaranteed. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 00:13 Message: Logged In: YES user_id=21627 I fail to see the problem. Can you please provide a scenario where breakage does occur (instead of merely suggesting that it "can occur")? What is the specific error message that you get? Also, what does that have to do with OS vendors? They shouldn't use the home scheme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
