Hi Ben,
Thank you for your rapid reply!
> > WHY Debian's installation of Python decided to diverge from a common
> > behavior on other distributions:
> > why in a hackish site.py those /usr/local paths are added?
> I don't know what “hackish” means here.
I meant to say "hackish fashion" I guess ;)
as for meanings:
dict hackish:
..skips..
Said of something that is or involves a hack.
dict hack:
..skips..
6. (Computers) A quick and inelegant, though functional
solution to a programming problem.
> I'll assume you are asking
> only “why are the ‘/usr/local/foo’ directories in the Python import
> search path?”.
rright ;)
> > what was the actual use-case they solved?
> As I understand it, the use case is analogous to the addition of
> ‘/usr/local/bin’ to the ‘PATH’ environment variable in the default
> shell profile.
ok -- that would be my next target! ;)
> > isn't it more natural for people installing smth under /usr/local
> What is ‘smth’? I can't find a package by that name.
sorry -- me typing fast
smth == something
> > to adjust their PYTHONPATH env variable and be happy without
> > interfering with other users of the system they share, who do not
> > want to use what is under /usr/local?
> Again, the idea of ‘/usr/local’ is that it allows the site
> administrator to install files, libraries, binaries, etc. that will
> override the OS-installed versions. Adjusting the search path so that
> those files are found first is necessary to allow that precedence.
so, freshly installed parts under /usr/local should precede system-wide
ones... why then keep system-wide installed parts at all? ok ok -- it
might be desired to keep packages in a sane state (ie not removing them
forcing depends, if there are packages which depend on them). I can only
then pride those who would need to figure out anything in the bug
reports (bless python which gives backtraces with full paths in them)
...sorry for non-constructive blurb here...
just to want to accent on the fact, that package versioning now in such
bug-reports becomes irrelevant if smth is preceded them in /usr/local.
> > why should I in my script to take care about infiltration of
> > /usr/local away from sys.path to prevent such interference mentioned
> > above?
> You would need to ask the system administrator who installed files in
> that location. Debian, according to Policy, never installs any program
> or library in ‘/usr/local’; that's the point.
I know that Debian never does such evil thing... that is why I usually
love to see my /usr/local as empty as possible ;) and I love Debian ;)
But what if I haven't made friends with my sysadmin? Am I doomed to
'infiltration' approach now?
> > why it was hardcoded in the distributed non-configuration site.py,
> > which I can't even "configure" to prevent such behavior without
> > doing tricks to prevent its automagic 'fix' on every upgrade?
> Can't the user who wants to avoid what the system administrator has
> deliberately put in place just modify their own ‘PYTHONPATH’
> environment variable? Again, analogous to the situation with shell
> executable search paths.
nope -- there is no PYTHONPATH env variable predefining those paths
(unlike PATH). site.py populates sys.path at runtime.
> > 1. remove /usr/local from site.py
> This denies the ability of the system administrator to put local
> overrides for Python library files in place as simply and consistently
> as is done for other libraries and executables.
indeed, precedence is smth I didn't think through in my suggested
approach.
I guess either making sys.path configurable in some config file under
/etc/, or controllable with
PYTHON_PRECEDE_LOCAL=1
environment variable handled in site.py, would resolve this
inconsistency.
There could be better solutions as well
> > 2. for convenience of users who like to run smth with /usr/local in
> > mind, but hate to tune PYTHONPATH
> What is ‘smth’, and how are its users different in their needs for a
> consisten search path precedence?
it is the same smth as above ;) sorry again
so far it is inconsistent with other distributions, as far as I see it
> Why are such users to be treated differently from those who override
> the ‘PATH’ variable?
> > is there anyone else who feels similar way?
> Perhaps, but the case has yet to be made why Python should be treated
> differently in this regard from so many other parts of the system.
does bash hard-code PATH inside its code? nope, it is in a configuration
file /etc/profile, and further can be tuned up in ~/.profile to
infiltrate ones for a session if desired. or better directly from
a configuration file, which /etc/profile is.
once again -- site.py is not a configuration file, it is not among other
configuration files (ie under /etc), there is no way to control the
situation now, besides begging sysadmin to remove his crap, or
populating the code with sys.path filtering list comprehensions, hence
making it incompatible with those systems where /local installation has
to be used for a good reason.
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student Ph.D. @ CS Dept. NJIT
Office: (973) 353-1412 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
