[csw-maintainers] Automatically excluding .pyc files

[Philip Brown]

On 10/14/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> ...
> If I have to choose between being consistent with how Perl is packaged
> and how Python is packaged, I'd go with the latter.  I don't see any
> real benefits for choosing the "one Python" strategy.  At the same
> time, I see serious downsides.  For example, if you write any serious
> Python code, you write it for a specific version, and you lock it down
> to that Python version.  You might migrate it later on to a newer
> version, but migration is a separate process.  You quite often need
> Python 2.4 to run some scripts, and Python 2.6 to run others.

That's..... kinda lame.
if python was some small runtime library thingie like berkeleydb, I
would just say okay fine. but python is a major set of packages.

As a comparison... not that sun always does things right, but solaris
10, 2010 ships with one and only one version of python.
(but a very old one. hrm.)

I think that, similar to ruby, we might be best served with a
"primary" version of python, and then some "if you really need it"
versions.
primary version gets /opt/csw/lib/python or whatever.

It should be pointed out that python, being interpreted, is different
from the way we handle shared libraries.  There can be only one
/opt/csw/bin/python. So in some ways, this is the most consistent
thing to do.
If we change /opt/csw/bin/python major version, then we SHOULD have to
recompile everything, methinks.

Does that make sense?

I'll also mention, that if we keep most things in /opt/csw/lib/python,
then a new version of /opt/csw/bin/python, can and should
automatically recompile everthing present there.
(that's the benefit of the unified no-number directory)
So for anything written portably, a version upgrade could be quite transparent.