I'm sure with you on this one. I wasted w..a..y too much time fiddling
with various settings and stepping through code to figure out this
unintuitive behavior.
The workarounds using virtual python and local environments seem too
"heavy" for my taste, as they override *all* installed libraries. Most
of the time I suspect that a developer would only want to override one
library -- the one that they are working on, or the one that is
suspected of giving a problem.
Overriding one library load location is a common use case that ought
to be easy to do, and the obvious and intuitive answer is to simply
modify the library load path. Breaking that metaphor is bad behavior.
On 2/6/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
> 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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---
