as I have like 12 different SA directories which id like to jump
between without going through a distinct install for each one, im a
big fan of PYTHONPATH, and after futile-ly arguing with PJE that plain
libraries on PYTHONPATH should take precedence over installed
".eggs" (he strongly feels that .eggs take precedence in all cases,
although others agree with me), I hacked my Python install to work the
way i wanted it:
put a file "aaaa-pythonpath.pth" into your site_packages folder:
import os, sys; sys.__egginsert=len(os.environ.get('PYTHONPATH',
'').split(os.pathsep));
this will send a modified path over to the easy-install.pth file which
is the culprit responsible for blowing up your PYTHONPATH. I continue
to use easy_install normally with no problems.
The SA unit test suite artifically shoves "./lib" into sys.path at
startup so that running SA unit tests should generally always use the
local checkout regardless of setuptools getting in the way.
if people are interested in more organized petitioning of PJE to
change his mind on this behavior, sign me up. generally people seem
to be unaware of it. I challenged him to name *any* scenario where an
administrator would want a local-environment-based PYTHONPATH to be
overridden by an application-wide configuration and he didnt reply to
that one. he sees it as a "if youre using .eggs, then you must accept
that PYTHONPATH only points to installation directories, not runtime
directories"...so basically breaking PYTHONPATH's documented behavior
into something repurposed is by design.
On Feb 6, 5:06 am, "King Simon-NFHD78" <[EMAIL PROTECTED]>
wrote:
> Rick Morrison wrote:
>
> > I keep two versions of SA installed here, one is a stable
> > version installed in the Python site-packages folder, and one
> > is current trunk with some local patches for testing.
>
> > I used to be able to run tests and programs using the local
> > version by just inserting the local directory into the Python
> > path, and imports would then use that.
>
> > I've recently upgraded to setuptools 0.6c5 and that doesn't
> > seem to work anymore -- I now always get the version from the
> > site-packages folder.
>
> > Anyone running this kind of configuration out there run into
> > something like this?
>
> The way I've done this is to run 'python setup.py develop' in the SVN
> checkout. This puts the path to the checkout in easy-install.pth, and it
> also creates an SQLAlchemy.egg-link file with the same path - I don't
> know what this is used for.
>
> To go back to the stable version I run 'easy_install -U SQLAlchemy'.
> This seems to work on both Windows and Linux, but I am only on
> setuptools 0.6c3.
>
> This is probably more complicated than it needs to be - I would have
> thought you can switch just by editing the easy-install.pth file.
>
> The correct way is probably to use setuptools' --multi-version switch,
> and put pkg_resources.require() somewhere in your application, but I've
> not used that yet.
>
> Another thing that I've found very useful (on Linux) is this:
>
> http://peak.telecommunity.com/DevCenter/EasyInstall#creating-a-virtual-p
> ython
>
> Particularly with fast-moving projects like SQLAlchemy and TurboGears,
> trying to share a single copy of a library between multiple applications
> without breaking them every time I upgraded the library was getting
> tricky. There's also working-env:
>
> http://blog.ianbicking.org/workingenv-update.html
>
> which I haven't tried yet, but has the advantage of working on Windows
> (apparently).
>
> Hope that helps,
>
> Simon
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
