[sqlalchemy] Re: new setuptools vs local SA copy
I found the thread about PYTHONPATH--interesting. It does seem that eggs are not only preventing the expected behavior, but they are also preventing the documented behavior. However, I don't think that using eggs is the best choice for a fast progressing library like SQLAlchemy--especially with this behavior. Plus, if the egg developer isn't participating in a discussion on this, why should that distribution method even be used? Paul --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: new setuptools vs local SA copy
On Jun 4, 1:58 pm, Paul Kippes [EMAIL PROTECTED] wrote: I found the thread about PYTHONPATH--interesting. It does seem that eggs are not only preventing the expected behavior, but they are also preventing the documented behavior. However, I don't think that using eggs is the best choice for a fast progressing library like SQLAlchemy--especially with this behavior. Plus, if the egg developer isn't participating in a discussion on this, why should that distribution method even be used? setuptools is the de-facto system for python distributions today. SA's presence within this system is already deeply embedded into the installation system of other products like turbogears and pylons. i think if a concerted effort to raise these issues on distutils-sig were made (there hasnt been), changes would be made. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: new setuptools vs local SA copy
On 6/4/07, Paul Kippes [EMAIL PROTECTED] wrote: I found the thread about PYTHONPATH--interesting. It does seem that eggs are not only preventing the expected behavior, but they are also preventing the documented behavior. However, I don't think that using eggs is the best choice for a fast progressing library like SQLAlchemy--especially with this behavior. Plus, if the egg developer isn't participating in a discussion on this, why should that distribution method even be used? Are you talking about this thread? http://mail.python.org/pipermail/distutils-sig/2007-May/007513.html I'm not sure that this is especially relevant to SQLAlchemy per se. Python has a language-wide problem in that: 1) Setuptools has become a de-facto standard but is not bundled with Python, forcing users to find and and install ez_setup.py. Users also have to do tricks with their site.py to get a local egg directory separate from site-packages, or use workingenv.py or Virtual Python. People who aren't Python programmers but just want to run an application (e.g., sysadmins) don't understand why they should have to do this -- it seems like a grave defect in the language and it turns them off from Python. 2) The distutils code is apparently very patched up and in need of a rewrite before setuptools is integrated, but there are no programmer volunteers to do it. 3) A few people don't like the setuptools approach and do not want it in the standard library. 4) Setuptools does not have an uninstall option or clean up old bin/ scripts. You can have two versions of an egg installed simultaneously but only one set of bin/ scripts, the latest-installed ones overwriting the previous. Over time you end up with a version mess and have to start again with a fresh library directory to clean it up, plus cleaning out the bin/ directory by hand. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: new setuptools vs local SA copy
On Jun 4, 2007, at 3:35 PM, Mike Orr wrote: On 6/4/07, Paul Kippes [EMAIL PROTECTED] wrote: I found the thread about PYTHONPATH--interesting. It does seem that eggs are not only preventing the expected behavior, but they are also preventing the documented behavior. However, I don't think that using eggs is the best choice for a fast progressing library like SQLAlchemy--especially with this behavior. Plus, if the egg developer isn't participating in a discussion on this, why should that distribution method even be used? Are you talking about this thread? http://mail.python.org/pipermail/distutils-sig/2007-May/007513.html FTR, my official this should be changed email is at: http://mail.python.org/pipermail/distutils-sig/2006-July/006492.html which was left unanswered by Eby. just had one response from someone who agrees with me. it all relies on this question: I cant think of a possible scenario where a path would explicitly exist in PYTHONPATH, non-egg or egg, where the user would still like the system-wide installation to take precedence, regardless of versioning or anything else. Otherwise why put the path on PYTHONPATH ? its also very easy to implement, as on my system where I just shoved an extra .pth file to make it happen. if it is in fact the case that setuptools thinks PYTHONPATH means something totally different for its purposes, which i think is Eby's take on this, it shouldnt be using PYTHONPATH for that purpose - it should use some other variable. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: new setuptools vs local SA copy
I have a directory on my laptop which looks like this:
./sa026
./sa027
./sa028
./sa030
./sa031
...
I set PYTHONPATH to ./lib. I change into each directory and run a
script that id like to compare between versions. No setup.py develop is
required...i dont want to install anything anywhere. I just want to use
*this source code right here*, even though an egg version of that software
happens to be installed somewhere. I dont see why thats so unreasonable.
basically right now, once you install something via setup.py, you can
never ever again use any module with that same name without going through
setuptools hoops for it (or shove a sys.path.insert() in your program,
or hack your python like i did).
Kumar McMillan wrote:
put a file -pythonpath.pth into your site_packages folder:
import os, sys; sys.__egginsert=len(os.environ.get('PYTHONPATH',
'').split(os.pathsep));
duly noted for future usage _when_ i meet an egg.
workingenv, as Simon King mentioned, is the way to go. At my company
we share a dev server which has lots of stuff complied for us but for
true isolated development, each developer needs his own python sandbox
to make egg links to all modules in progress.
$ sudo easy_install workingenv.py
$ python -m workingenv --site-packages ~/temp-py
$ source ~/temp-py/bin/activate
and now you can run `python setup.py develop` without sudo on any
package and it will only be available in that env, with a fallback to
site-packages for modules you haven't installed. And of course you
can have as many of these as you want.
Some things I've run into... when setuptools gets upgraded (why a
workingenv feature isn't built into setuptools, who knows) sometimes
you need to remove the setuptools egg and rebuild your workingenv the
same way you built it
$ python -m workingenv --site-packages ~/temp-py
this will not disturb any eggs or egg-links in your env.
The only alternative (quoted above) that I know is to hack your python
install (which I also did before workingenv). I still find workingenv
easier, tho not ideal.
I should also note that this was a perfect way to set up multiple
buildbot builders on our server.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: new setuptools vs local SA copy
python setup.py develop [1] doesn't install anything. It makes a link
to a directory of source code, just like you are doing w/ the
pythonpath, and you only have to run it once. either method is
accomplishing the same thing. I just find workingenv very easy to use
and wanted to share since there isn't really any documentation on it.
[1]
http://peak.telecommunity.com/DevCenter/setuptools#develop-deploy-the-project-source-in-development-mode
On 2/9/07, Michael Bayer [EMAIL PROTECTED] wrote:
I have a directory on my laptop which looks like this:
./sa026
./sa027
./sa028
./sa030
./sa031
...
I set PYTHONPATH to ./lib. I change into each directory and run a
script that id like to compare between versions. No setup.py develop is
required...i dont want to install anything anywhere. I just want to use
*this source code right here*, even though an egg version of that software
happens to be installed somewhere. I dont see why thats so unreasonable.
basically right now, once you install something via setup.py, you can
never ever again use any module with that same name without going through
setuptools hoops for it (or shove a sys.path.insert() in your program,
or hack your python like i did).
Kumar McMillan wrote:
put a file -pythonpath.pth into your site_packages folder:
import os, sys; sys.__egginsert=len(os.environ.get('PYTHONPATH',
'').split(os.pathsep));
duly noted for future usage _when_ i meet an egg.
workingenv, as Simon King mentioned, is the way to go. At my company
we share a dev server which has lots of stuff complied for us but for
true isolated development, each developer needs his own python sandbox
to make egg links to all modules in progress.
$ sudo easy_install workingenv.py
$ python -m workingenv --site-packages ~/temp-py
$ source ~/temp-py/bin/activate
and now you can run `python setup.py develop` without sudo on any
package and it will only be available in that env, with a fallback to
site-packages for modules you haven't installed. And of course you
can have as many of these as you want.
Some things I've run into... when setuptools gets upgraded (why a
workingenv feature isn't built into setuptools, who knows) sometimes
you need to remove the setuptools egg and rebuild your workingenv the
same way you built it
$ python -m workingenv --site-packages ~/temp-py
this will not disturb any eggs or egg-links in your env.
The only alternative (quoted above) that I know is to hack your python
install (which I also did before workingenv). I still find workingenv
easier, tho not ideal.
I should also note that this was a perfect way to set up multiple
buildbot builders on our server.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: new setuptools vs local SA copy
put a file -pythonpath.pth into your site_packages folder:
import os, sys; sys.__egginsert=len(os.environ.get('PYTHONPATH',
'').split(os.pathsep));
duly noted for future usage _when_ i meet an egg.
workingenv, as Simon King mentioned, is the way to go. At my company
we share a dev server which has lots of stuff complied for us but for
true isolated development, each developer needs his own python sandbox
to make egg links to all modules in progress.
$ sudo easy_install workingenv.py
$ python -m workingenv --site-packages ~/temp-py
$ source ~/temp-py/bin/activate
and now you can run `python setup.py develop` without sudo on any
package and it will only be available in that env, with a fallback to
site-packages for modules you haven't installed. And of course you
can have as many of these as you want.
Some things I've run into... when setuptools gets upgraded (why a
workingenv feature isn't built into setuptools, who knows) sometimes
you need to remove the setuptools egg and rebuild your workingenv the
same way you built it
$ python -m workingenv --site-packages ~/temp-py
this will not disturb any eggs or egg-links in your env.
The only alternative (quoted above) that I know is to hack your python
install (which I also did before workingenv). I still find workingenv
easier, tho not ideal.
I should also note that this was a perfect way to set up multiple
buildbot builders on our server.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: new setuptools vs local SA copy
[...] 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. I completely agree. I too have spent a lot of time finding why my PYTHONPATH was not considered anymore. Having it overridden is definitly not the expected behavior. -- Sébastien LELONG sebastien.lelong[at]sirloon.net --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: new setuptools vs local SA copy
u mean eggs will override pythonpath? that's bullshit!
one more reasone for me to hate eggs... be them cockroach' or python
ones...
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 -pythonpath.pth into your site_packages folder:
import os, sys; sys.__egginsert=len(os.environ.get('PYTHONPATH',
'').split(os.pathsep));
duly noted for future usage _when_ i meet an egg.
Here i have 4 SA installs, and switch them by re-pointing a symbolic
link in the global site-packages/. Which would not be possble if the
machine was shared - or i was using SA for something else that should
not break.
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.
hell, The whole idea of
having /home/my/bin /usr/local/bin /usr/bin /bin
in this order in the path is exactly that: so more-local behavior can
override more-global one (e.g. my own ls script overrides the
me-installed new-version /usr/local/ one which overrides the global
old-version /usr/bin/ which overrides the simplistic /bin one...
if he wants such behaviour, let him add a switch that force-ignores
PYTHONPATH or whatever other env-vars, and let the default stuff in
piece; all other reasonable apps behave this way.
svil
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: new setuptools vs local SA copy
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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: new setuptools vs local SA copy
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 -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
-~--~~~~--~~--~--~---
