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).

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.

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.

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.

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/

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.

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.

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.

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.

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.

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.

Logged In: YES 
user_id=21627

Unfortunately, the "vendor-packages" directory was never
really discussed. The only rationale I could find is from
Rich Burridge, on 09-20-2005, and says "We have been told
that this directory is inappropriate for vendor supplied
packages, just as "site_perl" is inappropriate for Perl."

This is hardly a convincing rationale: it is hearsay ("we
have been told", rather than "we believe"), and it suggests
that the only rationale for doing so is that Perl does so.
That couldn't convince me; the Perl way of doing things has
only in so far influenced Python as Perl was given as a bad
example which is not to follow in the past.

In any case, such discussion belongs to python-dev. I'm
personally not convinced that adding vendor-packages to
sys.path is necessary (why is site-packages not good
enough?), but I'm also not strongly opposed to add yet
another typically non-existing directory to the path
(especially since Python 2.5 caches the absence of the
directory so it gets skipped in subsequent imports)