Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
Greg Ewing writes: [EMAIL PROTECTED] wrote: I guess we're going to have to agree to disagree. I find hiding directories which contain executable code extremely non-obvious. I'm worried by this too. I don't like the idea of putting large and important things in hidden directories automatically without being told about it. So what we need is a PEP specifying that installers have -q and -v switches, defaulting to -v, right? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 1, 2008, at 8:03 PM, [EMAIL PROTECTED] wrote: Am I the only guy who finds software that insists on visible, fixed files in my home directory rude? vmware, for example, wants a ~/ vmware directory, but pretty much every other application I use is nice enough to use dotfiles (even cedega, with a roughly-comparable- to- lib applications I've installed for you folder). No Glyph, you are not alone! I don't even like the OS putting stuff like Pictures, Music, Movies, Videos and Desktop in my home directory, but I guess that's the price we pay for a modrin desktopy operatin' systum. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSCBAXHEjvBPtnXfVAQJdrgP+Mw0qZebL+MqUk3wKMsRt5mHzT/uHhQ0Z NVwyooWKWnvLMMifCbaG3pjVs7MehfcbAK8uLTlF8Ss9/w1Q5SWJkdhLMWOvHdA6 CJMvGyuokElD5e2cKXiakUWUshN/CeGNElTpxHUBdwmkirfXLQzQll9jlYbnr0I8 du2+rTj/oAc= =015L -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
2008/5/6 Barry Warsaw [EMAIL PROTECTED]: On May 1, 2008, at 8:03 PM, [EMAIL PROTECTED] wrote: Am I the only guy who finds software that insists on visible, fixed files in my home directory rude? vmware, for example, wants a ~/vmware directory, but pretty much every other application I use is nice enough to use dotfiles (even cedega, with a roughly-comparable-to- lib applications I've installed for you folder). No Glyph, you are not alone! I don't even like the OS putting stuff like Pictures, Music, Movies, Videos and Desktop in my home directory, but I guess that's the price we pay for a modrin desktopy operatin' systum. I too find this irritating. FWIW my vote is for ~/.python. ~/.local comes in a distant second due to non-obviousness and ~/Python is several light years beyond that. -- Evolution: Taking care of those too stupid to take care of themselves. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
Alec Thomas wrote: FWIW my vote is for ~/.python. ~/.local comes in a distant second due to non-obviousness and ~/Python is several light years beyond that. I think if the obviousness (or lack thereof) of the chosen directory name ever really matters to anyone, we did it wrong. After all, unless you're trying to use something other than distutils to get a package ready for installation, how often does it really matter that the site-packages directory for an installed python interpreter actually lives somewhere inside /usr/local? The main advantage I see to using the ~/.local approach is that a lot of questions about file layout (e.g. where to put architecture specific code) are automatically (and fairly obviously) answered Do whatever is done for the system-wide equivalent in /usr/local. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
Alec FWIW my vote is for ~/.python. ~/.local comes in a distant second Alec due to non-obviousness and ~/Python is several light years beyond Alec that. I guess we're going to have to agree to disagree. I find hiding directories which contain executable code extremely non-obvious. Would you prefer /usr/.local to /usr/local? If not, then why prefer ~/.local to ~/local? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
2008/5/7 [EMAIL PROTECTED]: Alec FWIW my vote is for ~/.python. ~/.local comes in a distant second Alec due to non-obviousness and ~/Python is several light years beyond Alec that. I guess we're going to have to agree to disagree. I find hiding directories which contain executable code extremely non-obvious. Would you prefer Python would not be unique. Mozilla/Firefox does exactly this, putting per-user plugins in ~/.mozilla. /usr/.local to /usr/local? If not, then why prefer ~/.local to ~/local? Because unlike a home directory, users don't frequently perform directory listings or tab completion of /usr/. For a frequently used personal directory one wants the minimum of noise. Also: 1. If every application followed the convention of creating non-hidden paths in home directories the directory listing would be *incredibly* noisy. To illustrate, I have 160 dotfiles, most of which were created by applications. I have only 8 non-hidden directories, all of which I have created myself. 2. Non-hidden directories interfere with tab completion muscle memory. 3. On a more subjective note, home directories are personal space. People shape them to their personality, and interfering with this is impolite. 4. Per-application dotfiles have 30 years of convention behind them. Conversely, only a few applications use ~/.local (for example, Openbox and Audacious both look for configuration here) and none that I'm aware of default to ~/local. 5. Applications that create non-hidden directories in user home directories are generally perceived as being obnoxious. -- Evolution: Taking care of those too stupid to take care of themselves. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
/usr/.local to /usr/local? If not, then why prefer ~/.local to ~/local? Because unlike a home directory, users don't frequently perform directory listings or tab completion of /usr/. For a frequently used personal directory one wants the minimum of noise. Glad someone around here knows actual facts about the statistics of using ls :-). Can you point to published user studies about this? If not, let me just say that I perform directory listings of /usr a whole lot *more* than my home directory. Um, isn't this all argument about what color to paint the shed? Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Tue, May 6, 2008 at 8:11 AM, Alec Thomas [EMAIL PROTECTED] wrote: Python would not be unique. Mozilla/Firefox does exactly this, putting per-user plugins in ~/.mozilla. Note that this is moot since I'm going to accept the PEP as it stands (i.e. ~/.local) but I want to point out something that seems to be lost occasionally. Hiding stuff in dot files is the right thing to do when there's a separate API (like Mozilla) to manage those files. It is IMO much more questionable when the user is expected to manage things directly using the standard filesystem API. That's why Pictures etc. are not dot files. Of course, there's a gray area -- grizzled Unix wizards manage dozens of dot files like .profile and .exrc -- but I still think this is a useful (partial) guiding principle. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Tue, May 6, 2008 at 7:37 AM, Steve Holden [EMAIL PROTECTED] wrote: If you want it visible, make a visible symbolic link! Note that the point is moot, since I'm going to accept Christian's PEP, i.e. ~/.local, but this argument you can make it visible yourself is bogus. The point of visibility (when it's brought up) isn't that you *can* make it visible -- you can always do that with ls -a or whatever Finder option. The point is that (in some people's view) the results of an action should be left *in plain sight* so that the user has clear evidence of what happened. I'm fine in this case with the counterarguments though, so I'll be accepting the PEP in a minute. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
/usr/.local to /usr/local? If not, then why prefer ~/.local to ~/local? Alec Because unlike a home directory, users don't frequently perform Alec directory listings or tab completion of /usr/. For a frequently Alec used personal directory one wants the minimum of noise. I don't mind the system clearly telling me about code I've installed. That's a lot different than Mozilla hiding it's internal stuff in ~/.mozilla. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
[EMAIL PROTECTED] wrote: I guess we're going to have to agree to disagree. I find hiding directories which contain executable code extremely non-obvious. I'm worried by this too. I don't like the idea of putting large and important things in hidden directories automatically without being told about it. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
Steve Holden wrote: If you want it visible, make a visible symbolic link! I have to know it's there first. The idea of an installer deliberately hiding stuff from me in a very unconventional and non-obvious way makes me uncomfortable. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Thu, May 1, 2008 at 10:26 PM, Barry Warsaw [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a reminder that the LAST planned alpha releases of Python 2.6 and 3.0 are scheduled for next Wednesday, 07-May-2008. Please be diligent over the next week so that none of your changes break Python. The stable buildbots look moderately okay, let's see what we can do about getting them all green: http://www.python.org/dev/buildbot/stable/ We have a few showstopper bugs, and I will be looking at these more carefully starting next week. http://bugs.python.org/[EMAIL PROTECTED],id,activity,versions,status@sort=activity@filter=priority,status@pagesize=50@startwith=0priority=1status=1@dispname=Showstoppers running the testsuite segfaults on my 64 bit debian testing in test_pyexpat. This does not happen in a debug build: test_pyclbr test_pydoc test_pyexpat Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2b573851a6e0 (LWP 19486)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x2f694f0a in doContent (parser=0x1b4bab0, startTagLevel=0, enc=0x1b4dba0, s=0x1b4cb3c /s, ' ' repeats 23 times, frozenset([frozenset([2]),\n, ' ' repeats 67 times, frozenset([0,\n, ' ' repeats 65 times..., end=0x1b4cb40 ' ' repeats 23 times, frozenset([frozenset([2]),\n, ' ' repeats 67 times, frozenset([0,\n, ' ' repeats 69 times..., nextPtr=0x1b4bae0, haveMore=1 '\001') at extensions/expat/lib/xmlparse.c:2540 #2 0x2f6972ee in contentProcessor (parser=0x1b4bab0, start=0x0, end=0x1b4c470 q\001, endPtr=0x0) at extensions/expat/lib/xmlparse.c:2003 #3 0x2f698662 in doProlog (parser=0x1b4bab0, enc=0x1b4dba0, s=0x1b4c738 s, 'a' repeats 197 times..., end=0x1b4cb40 ' ' repeats 23 times, frozenset([frozenset([2]),\n, ' ' repeats 67 times, frozenset([0,\n, ' ' repeats 69 times..., tok=29, next=0x1b4c738 s, 'a' repeats 197 times..., nextPtr=0x1b4bae0, haveMore=1 '\001') at extensions/expat/lib/xmlparse.c:3803 #4 0x2f69adc3 in prologInitProcessor (parser=0x1b4bab0, s=0x1b4c710 ?xml version='1.0' encoding='iso8859'?s, 'a' repeats 157 times..., end=0x1b4cb40 ' ' repeats 23 times, frozenset([frozenset([2]),\n, ' ' repeats 67 times, frozenset([0,\n, ' ' repeats 69 times..., nextPtr=0x1b4bae0) at extensions/expat/lib/xmlparse.c:3551 #5 0x2f68cc61 in XML_ParseBuffer (parser=0x1d20670, len=28625724, isFinal=0) at extensions/expat/lib/xmlparse.c:1562 #6 0x2f689467 in xmlparse_Parse (self=0x1d20670, args=value optimized out) at extensions/pyexpat.c:922 #7 0x00419b9d in PyObject_Call (func=0x1a52b48, arg=0x2b7a710, kw=0x1b4c610) at Objects/abstract.c:2490 #8 0x004902f8 in PyEval_EvalFrameEx (f=0x8cba40, throwflag=value optimized out) at Python/ceval.c:3944 #9 0x00494824 in PyEval_EvalCodeEx (co=0x2b5738764558, globals=value optimized out, locals=value optimized out, args=0x23aa130, argcount=4, kws=0x23aa150, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2908 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Fri, May 02, 2008, Barry Warsaw wrote: On May 2, 2008, at 1:48 AM, [EMAIL PROTECTED] wrote: In the long term, if everyone followed suit on ~/.local, that would be great. But I don't want a ~/Python, ~/Java, ~/Ruby, ~/PHP, ~/Perl, ~/OCaml and ~/Erlang and a $PATH as long as my arm just so I can run a few applications without system- installing them. I hate to send a me too messages, but I have to say Glyph is exactly right here. +1 -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Help a hearing-impaired person: http://rule6.info/hearing.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On 3 May, 11:34 pm, [EMAIL PROTECTED] wrote: On May 3, 2008, at 7:51 AM, [EMAIL PROTECTED] wrote: Fred asked for a --prefix flag (which is what I was voting on). I don't really care what you do by default as long as you give me a way to do it differently. What's most interesting (to me) is that no one's commented on my note that my preferred approach would be that there's no default at all; the location would have to be specified explicitly. Whether on the command line or in the distutils configuration doesn't matter, but explicitness should be required. I thought I responded to it in my initial response, but let me be clearer. First, Skip, I *only* care about the default behavior. There's already a way to do it differently: PYTHONPATH. So, Fred, I think what you're arguing for is to drop this feature entirely. Or is there some other use for a new way to allow users to explicitly add something to sys.path, aside from PYTHONPATH? It seems that it would add more complexity and I can't see what the value would be. As I've said a dozen times in this thread already, the feature I'd like to get from a per-user installation location is that 'setup.py install', or at least some completely canonical distutils incantation, should work, by default, for non-root users; ideally non-administrators on windows as well as non-root users on unixish platforms. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
glyph As I've said a dozen times in this thread already, the feature glyph I'd like to get from a per-user installation location is that glyph 'setup.py install', or at least some completely canonical glyph distutils incantation, should work, by default, for non-root glyph users; ideally non-administrators on windows as well as non-root glyph users on unixish platforms. I'm unclear why anything needs changing then. At work we have idiosyncratic central install locations for everything, not just Python. None of this stuff is installed by root. When I want to install some package to test without polluting the central waters I simply run setup.py install with a --prefix arg then set PYTHONPATH to pick up my stuff before the central stuff. I see no reason to change the behavior of setup.py's install command. It gives you the flexibility needed to handle a number of different scenarios. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Sun, May 4, 2008 at 9:58 AM, [EMAIL PROTECTED] wrote: ...snip... As I've said a dozen times in this thread already, the feature I'd like to get from a per-user installation location is that 'setup.py install', or at least some completely canonical distutils incantation, should work, by default, for non-root users; ideally non-administrators on windows as well as non-root users on unixish platforms. This is a big +1 from me. The way I currently work around the must be root to install stuff on both OS/X and other Lin/Uni(xes) is via virtualenv.py and a lot of bash environment trickery. If nothing else comes out of this, I think what glyph points out is the ideal, and simplest goal. Ignoring the directory name debate, I would like to see this local user dir mirror the normal directory tree that packages installed from distutils/setuptools typically use, namely it should have the: lib/site-packages/your module here and bin/your scripts here directories, and a known parent name. One thing that could be done is pick a default name for the parent, ala ~/Python - but let users override it with an environment variable if they so desire (PYTHON_USER_DIR?) so that those who want it hidden can have it hidden, and those of us who don't, don't. -jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
First, Skip, I *only* care about the default behavior. There's already a way to do it differently: PYTHONPATH. So, Fred, I think what you're arguing for is to drop this feature entirely. Or is there some other use for a new way to allow users to explicitly add something to sys.path, aside from PYTHONPATH? It seems that it would add more complexity and I can't see what the value would be. PYTHONPATH is lacking one feature which is important for lots of packages and setuptools. The directories in PYTHONPATH are just added to sys.path. But setuptools require a site package directory. Maybe a new env var PYTHONSITEPATH could solve the problem. As I've said a dozen times in this thread already, the feature I'd like to get from a per-user installation location is that 'setup.py install', or at least some completely canonical distutils incantation, should work, by default, for non-root users; ideally non-administrators on windows as well as non-root users on unixish platforms. The implementation of my PEP provides a new option for install: $ python setup.py install --user Is it sufficient for you? Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
Nick Coghlan schrieb:
- for experienced users (Barry, skip, etc) that want ~/.local to be more
easily accessible, creating a visible ~/local symlink is an utterly
trivial exercise.
Our you can set the environment variable PYTHONUSERBASE to $HOME.
PYTHONUSERBASE is the root directory for user specific data:
def addusersitepackages(known_paths):
Add a per user site-package to sys.path
Each user has its own python directory with site-packages in the
home directory.
USER_BASE is the root directory for all Python versions
USER_SITE is the user specific site-packages directory
USER_SITE/.. can be used for data.
global USER_BASE, USER_SITE
env_base = os.environ.get(PYTHONUSERBASE, None)
def joinuser(*args):
return os.path.expanduser(os.path.join(*args))
#if sys.platform in ('os2emx', 'riscos'):
## Don't know what to put here
#USER_BASE = ''
#USER_SITE = ''
if os.name == nt:
base = os.environ.get(APPDATA) or ~
USER_BASE = env_base if env_base else joinuser(base, Python)
USER_SITE = os.path.join(USER_BASE,
Python + sys.version[0] + sys.version[2],
site-packages)
else:
USER_BASE = env_base if env_base else joinuser(~, .local)
USER_SITE = os.path.join(USER_BASE, lib,
python + sys.version[:3],
site-packages)
if os.path.isdir(USER_SITE):
addsitedir(USER_SITE, known_paths)
return known_paths
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On 2008-05-04 18:14, Christian Heimes wrote: First, Skip, I *only* care about the default behavior. There's already a way to do it differently: PYTHONPATH. So, Fred, I think what you're arguing for is to drop this feature entirely. Or is there some other use for a new way to allow users to explicitly add something to sys.path, aside from PYTHONPATH? It seems that it would add more complexity and I can't see what the value would be. PYTHONPATH is lacking one feature which is important for lots of packages and setuptools. The directories in PYTHONPATH are just added to sys.path. But setuptools require a site package directory. Maybe a new env var PYTHONSITEPATH could solve the problem. We don't need another setup variable for this. Just place a well-known module into the site-packages/ directory and then query it's __file__ attribute, e.g. site-packages/site_packages.py The module could even include a few helpers to query various settings which apply to the site packages directory, e.g. site_packages.get_dir() site_packages.list_packages() site_packages.list_modules() etc. As I've said a dozen times in this thread already, the feature I'd like to get from a per-user installation location is that 'setup.py install', or at least some completely canonical distutils incantation, should work, by default, for non-root users; ideally non-administrators on windows as well as non-root users on unixish platforms. The implementation of my PEP provides a new option for install: $ python setup.py install --user Is it sufficient for you? Just in case you don't know... python setup.py install --home=~ will install to ~/lib/python The problem is not getting the packages installed in a non-admin location. It's about Python looking in a non-admin location per default (as well as in the site-packages location). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 04 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
M.-A. Lemburg schrieb: PYTHONPATH is lacking one feature which is important for lots of packages and setuptools. The directories in PYTHONPATH are just added to sys.path. But setuptools require a site package directory. Maybe a new env var PYTHONSITEPATH could solve the problem. We don't need another setup variable for this. Just place a well-known module into the site-packages/ directory and then query it's __file__ attribute, e.g. site-packages/site_packages.py The module could even include a few helpers to query various settings which apply to the site packages directory, e.g. site_packages.get_dir() site_packages.list_packages() site_packages.list_modules() etc. I don't see how it is going to solve the use case Add another site package directory when I don't have write access to the global site package directory and I don't want to modify my apps. Just in case you don't know... python setup.py install --home=~ will install to ~/lib/python The problem is not getting the packages installed in a non-admin location. It's about Python looking in a non-admin location per default (as well as in the site-packages location). I know the --home option. For one the --home option is Unix only and not supported on Windows Also the --user option takes all options of my PEP 370 user site directory into account, includinge the PYTHONUSERBASE env var. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On 2008-05-04 21:57, Christian Heimes wrote: M.-A. Lemburg schrieb: PYTHONPATH is lacking one feature which is important for lots of packages and setuptools. The directories in PYTHONPATH are just added to sys.path. But setuptools require a site package directory. Maybe a new env var PYTHONSITEPATH could solve the problem. We don't need another setup variable for this. Just place a well-known module into the site-packages/ directory and then query it's __file__ attribute, e.g. site-packages/site_packages.py The module could even include a few helpers to query various settings which apply to the site packages directory, e.g. site_packages.get_dir() site_packages.list_packages() site_packages.list_modules() etc. I don't see how it is going to solve the use case Add another site package directory when I don't have write access to the global site package directory and I don't want to modify my apps. No, but it's going to solve the issue which of the sys.path directories is to be considered the site packages directory. I was under the impression that this is what you were after. Just in case you don't know... python setup.py install --home=~ will install to ~/lib/python The problem is not getting the packages installed in a non-admin location. It's about Python looking in a non-admin location per default (as well as in the site-packages location). I know the --home option. For one the --home option is Unix only and not supported on Windows Also the --user option takes all options of my PEP 370 user site directory into account, includinge the PYTHONUSERBASE env var. Ok. Just wanted to mention that there is a precedent in distutils for doing user home directory installations. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 04 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
[EMAIL PROTECTED] wrote: Fred If user-local package installs went to ~/ by default ... with a Fred way to set an alternate prefix instead of ~/ using a distutils Fred configuration setting, I'd be happy enough. +1 from me. But then we clutter up people's (read *my*) home directory with no way for them to do anything about it. We should stay out of people's way by default, while making it easy for them to poke around if they want to. The ~/.local convention does that, but using ~/ directly does not. The major reasons why I think staying out of people's way by default is important: - for people like me (glyph, Georg, etc), it allows us to keep our home directory organised the way we like it. As far as I am concered, applications can store whatever user-specific configuration and data files they like inside hidden files or directories, but they shouldn't be inflicting any visible files on me that aren't related to things I am working on. - for novice users, the fact that it's hidden helps keep them from deleting it by accident - for experienced users (Barry, skip, etc) that want ~/.local to be more easily accessible, creating a visible ~/local symlink is an utterly trivial exercise. Switching the default to use public directories instead of hidden ones helps the third group at the expense of the first two groups. Given that the third group already has an easy workaround to get the behaviour they want, that seems like a bad trade-off to me. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
Nick [EMAIL PROTECTED] wrote: Fred If user-local package installs went to ~/ by default ... with a Fred way to set an alternate prefix instead of ~/ using a distutils Fred configuration setting, I'd be happy enough. Skip +1 from me. Nick But then we clutter up people's (read *my*) home directory with no Nick way for them to do anything about it. Fred asked for a --prefix flag (which is what I was voting on). I don't really care what you do by default as long as you give me a way to do it differently. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
- for experienced users (Barry, skip, etc) that want ~/.local to be more easily accessible, creating a visible ~/local symlink is an utterly trivial exercise. Barry Hey Nick, I agree with everything above, except that I'd probably Barry put myself more in Glyph's camp :). Can't speak for Skip Barry though... I already install everything in ~/local and just have ~/local/bin in my PATH. If I lived in a truly platform-dependent world I'd add platform-dependent ~/local-plat1, ~/local/plat2, etc directories and extend PATH a bit more. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 3, 2008, at 5:05 AM, Nick Coghlan wrote: The major reasons why I think staying out of people's way by default is important: - for people like me (glyph, Georg, etc), it allows us to keep our home directory organised the way we like it. As far as I am concered, applications can store whatever user-specific configuration and data files they like inside hidden files or directories, but they shouldn't be inflicting any visible files on me that aren't related to things I am working on. - for novice users, the fact that it's hidden helps keep them from deleting it by accident - for experienced users (Barry, skip, etc) that want ~/.local to be more easily accessible, creating a visible ~/local symlink is an utterly trivial exercise. Hey Nick, I agree with everything above, except that I'd probably put myself more in Glyph's camp :). Can't speak for Skip though... - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSBxkSXEjvBPtnXfVAQKSigP/d6HIeQ5QLZR4QZ7GAIttb0d+8JI6PM0e 3E2+br0jZ9IeDwjjCLIAx1kbfgIX56++NGoU7tQqiQtbcapI3H3Vb+X+VSAcs30L ORj709MDtF2oqXSzEHww5HHeKoZiQ8/FfiaZoXrXzqPVP5k9MSZu1zLrT3rpWAUP 8YLFekz/LUA= =l5be -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
Barry Warsaw wrote: On May 3, 2008, at 5:05 AM, Nick Coghlan wrote: - for experienced users (Barry, skip, etc) that want ~/.local to be more easily accessible, creating a visible ~/local symlink is an utterly trivial exercise. Hey Nick, I agree with everything above, except that I'd probably put myself more in Glyph's camp :). Can't speak for Skip though... I was actually looking at something Fred wrote and managed to misread it as something you had posted - and it turns out Skip was just agreeing with Fred about the 'provide an option to tell distutils to use a different user-specific directory name than the default one' idea, and isn't particularly worried about where the packages go by default. Sorry for the confusion. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On May 3, 2008, at 7:51 AM, [EMAIL PROTECTED] wrote: Fred asked for a --prefix flag (which is what I was voting on). I don't really care what you do by default as long as you give me a way to do it differently. What's most interesting (to me) is that no one's commented on my note that my preferred approach would be that there's no default at all; the location would have to be specified explicitly. Whether on the command line or in the distutils configuration doesn't matter, but explicitness should be required. -Fred -- Fred Drake fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
Fred Drake wrote: On May 3, 2008, at 7:51 AM, [EMAIL PROTECTED] wrote: Fred asked for a --prefix flag (which is what I was voting on). I don't really care what you do by default as long as you give me a way to do it differently. What's most interesting (to me) is that no one's commented on my note that my preferred approach would be that there's no default at all; the location would have to be specified explicitly. Whether on the command line or in the distutils configuration doesn't matter, but explicitness should be required. I thought Christian said something about that defeating one of the main points of the PEP - to allow per-user installation of modules to just work for non-administrators. (It may not have been Christian, and it may not have been directly in response to you, but I'm pretty sure I read it somewhere in this thread ;) Anyway, a per-user site-packages directly only just works if the standard behaviour of a Python installation is to provide access to the per-user packages without requiring any additional action on the part of the user. A couple of paragraphs in the PEP may also be of interest to you: For security reasons the user site directory is not added to sys.path when the effective user id or group id is not equal to the process uid / gid [9]. It's an additional barrier against code injection into suid apps. However Python suid scripts must always use the -E and -s option or users can sneak in their own code. The user site directory can be suppressed with a new option -s or the environment variable PYTHONNOUSERSITE. The feature can be disabled globally by setting site.ENABLE_USER_SITE to the value False. It must be set by editing site.py. It can't be altered in sitecustomize.py or later. So Python itself turns the feature off automatically for invocation via sudo and the like, and the sysadmin can disable the feature completely through site.py. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 2, 2008, at 1:48 AM, [EMAIL PROTECTED] wrote: etc, though. In the long term, if everyone followed suit on ~/.local, that would be great. But I don't want a ~/Python, ~/Java, ~/Ruby, ~/PHP, ~/Perl, ~/OCaml and ~/Erlang and a $PATH as long as my arm just so I can run a few applications without system- installing them. I hate to send a me too messages, but I have to say Glyph is exactly right here. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSBr75XEjvBPtnXfVAQIHAgP+JDpOymVEKfFvzZQZd8WtTpY6jsjvntAA 2J38LslMAXJSs3BcRBU/ELcbvTpr/JoEButktAQJCJpIhsmRTV0y3KcS/d/d+Sao 9V3ME2/yZ94qeQheB7jJIhfihNlC7VhG+CjSOMZrRZwm3k2drGGDdfdgGeSGZJOl B6uCEB0i0iI= =gup1 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
Barry Warsaw wrote: Time is running short to get any new features into Python 2.6 and 3.0. The release after this one is scheduled to be the first beta release, at which time we will institute a feature freeze. If your feature doesn't make it in by then, you'll have to wait until 2.7/3.1. If there is something that absolutely must go into 2.6/3.0 be sure that there is a bug issue open for it and that the Priority is set to 'release blocker'. I may reduce it to critical for the next alpha, but we'll review all the release blocker and critical issues for the first 2.6 and 3.0 beta releases. I tried to bump http://bugs.python.org/issue643841 (New class special method lookup change) up to release blocker, but the bug tracker still appears to be a bit flaky (it keeps giving me an error when I try to submit the change - unfortunately I can't submit anything about it to the metatracker, because I've forgotten my password for it and the metatracker is getting a connection refused when it tries to send the reminder email :P). Here's the comment I was trying to submit along with the bug priority change: Bumping the priority on this to release blocker for 3.0 - I think we need to have a good answer for the folks who've written old-style __getattr__ based auto-delegating classes before removing old-style classes entirely in 3.0. We could get away with ignoring the issue in the past because people had the option of just using an old-style class rather than having to deal with the difficulties of doing this with a new-style class. With 3.0, that approach is being eliminated. A ProxyMixin class written in Python would address that need (and shouldn't be particularly hard to write), but I'm not sure where it would go in the standard library. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
Windows and Mac OS X have dedicated directories for application specific
libraries. That is ~/Library on Mac and Application Data on Windows.
In fact, I had to write code for this, and had to read the specs for each.
Here's the code (I've substituted Python for UpLib):
if sys.platform == 'darwin':
listdir = os.path.expanduser(os.path.join(~, Library, Application
Support, org.python))
elif sys.platform == 'win32':
if os.environ.has_key('APPDATA'):
listdir = os.path.join(os.environ['APPDATA'], 'Python')
elif os.environ.has_key('USERPROFILE'):
listdir = os.path.join(os.environ['USERPROFILE'], 'Application Data',
'Python')
elif os.environ.has_key('HOMEDIR') and os.environ.has_key('HOMEPATH'):
listdir = os.path.join(os.environ['HOMEDIR'], os.environ['HOMEPATH'],
'Python')
else:
listdir = os.path.join(os.path.expanduser(~), 'Python')
else:
# pretty much has to be unix
listdir = os.path.expanduser(os.path.join(~, .python))
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On 05:53 pm, [EMAIL PROTECTED] wrote: On May 1, 2008, at 7:54 PM, Barry Warsaw wrote: Interesting. I'm of the opposite opinion. I really don't want Python dictating to me what my home directory should look like (a dot file doesn't count because so many tools conspire to hide it from me). I guess there's always $PYTHONUSERBASE, but I think I will not be alone. ;) Using ~/.local/ for user-managed content doesn't seem right to me at all, because it's hidden by default. I don't understand your reason for saying this. Terms like user and manage are somewhat vague. What sort of experience are you hoping to provide what sort of user with this convention? I hope my earlier explanations were clear as far as the types of users. I believe that the management of ~/.local/ is a subtle question. It will largely be managed by simply telling distutils to put files there; I hope, implicitly. In my mind there are 2 types of users who will be managing it - newbies, who don't really know what's going on but want cd mypackage-0.0.1; python setup.py install; python -c 'import mypackage' (or perhaps even easy_install mypackage) to work, and advanced users who want to be able to mix-and-match different versions of different packages. Advanced users might already have a PYTHONPATH management (virtual python, virtualenv, combinator, ~/.bashrc hacks, a directory full of symlinks) that already works for them, or be comfortable with inspecting a hidden directory, so ~/.local isn't a problem for them (i.e. us); newbies don't want to see the directory until they already know what's going on. I'd be even happier if there were no default per-user location, but a required configuration setting (in the existing distutils config locations) in order to enable per-user installation. If you're happier without this feature, then perhaps your tastes run counter to a useful implementation of it :). Why wouldn't you want it, though? PYTHONPATH still exists; you don't have to use it, personally. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
Fred If user-local package installs went to ~/ by default ... with a Fred way to set an alternate prefix instead of ~/ using a distutils Fred configuration setting, I'd be happy enough. +1 from me. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Thu, May 1, 2008 at 2:27 PM, Christian Heimes [EMAIL PROTECTED] wrote: Barry Warsaw schrieb: This is a reminder that the LAST planned alpha releases of Python 2.6 and 3.0 are scheduled for next Wednesday, 07-May-2008. Please be diligent over the next week so that none of your changes break Python. The stable buildbots look moderately okay, let's see what we can do about getting them all green: I like to draw some attention to two features for the last alpha: PEP 370: Per user site-packages directory http://www.python.org/dev/peps/pep-0370/ I like this, except one issue: I really don't like the .local directory. I don't see any compelling reason why this needs to be ~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide it from view, especially since the user is expected to manage this explicitly. Alternative memory allocation for ints, floats and longs using PyMalloc instead of the current block allocation. The issue has been discussed in great length a few months ago but without a final decision. http://bugs.python.org/issue2039 I might look at this later; but it seems to me to be a pure optimization and thus not required to be in before the first beta. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 1, 2008, at 7:45 PM, Guido van Rossum wrote: On Thu, May 1, 2008 at 2:27 PM, Christian Heimes [EMAIL PROTECTED] wrote: Barry Warsaw schrieb: This is a reminder that the LAST planned alpha releases of Python 2.6 and 3.0 are scheduled for next Wednesday, 07-May-2008. Please be diligent over the next week so that none of your changes break Python. The stable buildbots look moderately okay, let's see what we can do about getting them all green: I like to draw some attention to two features for the last alpha: PEP 370: Per user site-packages directory http://www.python.org/dev/peps/pep-0370/ I like this, except one issue: I really don't like the .local directory. I don't see any compelling reason why this needs to be ~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide it from view, especially since the user is expected to manage this explicitly. Interesting. I'm of the opposite opinion. I really don't want Python dictating to me what my home directory should look like (a dot file doesn't count because so many tools conspire to hide it from me). I guess there's always $PYTHONUSERBASE, but I think I will not be alone. ;) - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSBpYQ3EjvBPtnXfVAQLY+AP/dy7qoQKNEJiKtlwqCtw7LUCMLMQylBX8 DfbIonOnAaKHzjveyswuxVeAEq/C/fxssOGMhyd++H/1koJHjBdIHp47+RgohbHQ 1xCyA6Qj8f6xM3xdCR7lRuIDdjb6Tb/iCIQT/dHLrYxEf+VGUC+xVa3JIXdfJu4s kUYg7tU8SQ8= =xJWG -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On 11:45 pm, [EMAIL PROTECTED] wrote: I like this, except one issue: I really don't like the .local directory. I don't see any compelling reason why this needs to be ~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide it from view, especially since the user is expected to manage this explicitly. I've previously given a spirited defense of ~/.local on this list ( http://mail.python.org/pipermail/python-dev/2008-January/076173.html ) among other places. Briefly, lib is not the only directory participating in this convention; you've also got the full complement of other stuff that might go into an installation like /usr/local. So, while lib might annoy me a little, bin etc games include lib lib32 man sbin share src is going to get ugly pretty fast, especially if this is what comes up in Finder or Nautilus or Explorer every time I open a window. If it's going to be a visible directory on the grounds that this is a Python- specific thing that is explicitly *not* participating in a convention with other software, then please call it ~/Python or something. Am I the only guy who finds software that insists on visible, fixed files in my home directory rude? vmware, for example, wants a ~/vmware directory, but pretty much every other application I use is nice enough to use dotfiles (even cedega, with a roughly-comparable-to- lib applications I've installed for you folder). Put another way - it's trivial to make ~/.local/lib show up by symlinking ~/lib, but you can't make ~/lib disappear, and lots of software ends up looking at ~. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Thu, May 1, 2008 at 5:03 PM, [EMAIL PROTECTED] wrote: On 11:45 pm, [EMAIL PROTECTED] wrote: I like this, except one issue: I really don't like the .local directory. I don't see any compelling reason why this needs to be ~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide it from view, especially since the user is expected to manage this explicitly. I've previously given a spirited defense of ~/.local on this list ( http://mail.python.org/pipermail/python-dev/2008-January/076173.html ) among other places. Briefly, lib is not the only directory participating in this convention; you've also got the full complement of other stuff that might go into an installation like /usr/local. So, while lib might annoy me a little, bin etc games include lib lib32 man sbin share src is going to get ugly pretty fast, especially if this is what comes up in Finder or Nautilus or Explorer every time I open a window. Unless I misread the PEP, there's only going to be a lib subdirectory. Python packages don't put stuff in other places AFAIK. On the Mac, the default Finder window is not your home directory but your Desktop, which is a subdirectory thereof with a markedly public name. In fact, OS X has a whole bunch of reserved names in your home directory, and none of them start with a dot. The rule seems to be that if it contains stuff that the user cares about, it doesn't start with a dot. If it's going to be a visible directory on the grounds that this is a Python- specific thing that is explicitly *not* participating in a convention with other software, then please call it ~/Python or something. Much better than ~/.local/ IMO. Am I the only guy who finds software that insists on visible, fixed files in my home directory rude? vmware, for example, wants a ~/vmware directory, but pretty much every other application I use is nice enough to use dotfiles (even cedega, with a roughly-comparable-to- lib applications I've installed for you folder). The distinction to my mind is that most dot files (with the exception of a few like .profile or .bashrc) are not managed by most users -- the apps that manage them provide an APIs for manipulating their contents. (Sort of like thw Windows registry.) Non-dot files are for stuff that the user needs to be aware of. I'm not sure where Python packages fall, but ISTM that this is something a user must explicitly choose as the target of an installer. The user is also likely to have to dig through there to remove stuff, as Python package management doesn't have a way to remove packages. Put another way - it's trivial to make ~/.local/lib show up by symlinking ~/lib, That's not the same thing at all. but you can't make ~/lib disappear, and lots of software ends up looking at ~. But what software cares about another file there? My home directory is mostly a switching point where I have quick access to everything I access regularly. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Thu, May 1, 2008 at 1:26 PM, Barry Warsaw [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a reminder that the LAST planned alpha releases of Python 2.6 and 3.0 are scheduled for next Wednesday, 07-May-2008. Please be diligent over the next week so that none of your changes break Python. The stable buildbots look moderately okay, let's see what we can do about getting them all green: http://www.python.org/dev/buildbot/stable/ We have a few showstopper bugs, and I will be looking at these more carefully starting next week. http://bugs.python.org/[EMAIL PROTECTED],id,activity,versions,status@sort=activity@filter=priority,status@pagesize=50@startwith=0priority=1status=1@dispname=Showstoppers Time is running short to get any new features into Python 2.6 and 3.0. The release after this one is scheduled to be the first beta release, at which time we will institute a feature freeze. If your feature doesn't make it in by then, you'll have to wait until 2.7/3.1. If there is something that absolutely must go into 2.6/3.0 be sure that there is a bug issue open for it and that the Priority is set to 'release blocker'. I may reduce it to critical for the next alpha, but we'll review all the release blocker and critical issues for the first 2.6 and 3.0 beta releases. I just closed the release blocker I created (the backwards-compatibility issue with warnings.showwarning() ). I would like to add a PendingDeprecationWarning (or stronger) to 2.6 for showwarning() implementations that don't support the optional 'line' argument. I guess the best way to do it in C code would be to see if PyFunction_GetDefaults() returns a tuple of length two (since showwarning() already has a single optional argument as it is). Anyone have an issue with me doing this? Is PendingDeprecationWarning safe enough for 2.6? Or should this be a 3.0-only thing with a DeprecationWarning? -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Thu, May 1, 2008 at 9:31 PM, Brett Cannon [EMAIL PROTECTED] wrote: I just closed the release blocker I created (the backwards-compatibility issue with warnings.showwarning() ). I would like to add a PendingDeprecationWarning (or stronger) to 2.6 for showwarning() implementations that don't support the optional 'line' argument. I guess the best way to do it in C code would be to see if PyFunction_GetDefaults() returns a tuple of length two (since showwarning() already has a single optional argument as it is). Anyone have an issue with me doing this? Is PendingDeprecationWarning safe enough for 2.6? Or should this be a 3.0-only thing with a DeprecationWarning? I vote for a full DeprecationWarning. -Brett -- Cheers, Benjamin Peterson ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
Guido van Rossum schrieb: On Thu, May 1, 2008 at 5:03 PM, [EMAIL PROTECTED] wrote: On 11:45 pm, [EMAIL PROTECTED] wrote: I like this, except one issue: I really don't like the .local directory. I don't see any compelling reason why this needs to be ~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide it from view, especially since the user is expected to manage this explicitly. I've previously given a spirited defense of ~/.local on this list ( http://mail.python.org/pipermail/python-dev/2008-January/076173.html ) among other places. Briefly, lib is not the only directory participating in this convention; you've also got the full complement of other stuff that might go into an installation like /usr/local. So, while lib might annoy me a little, bin etc games include lib lib32 man sbin share src is going to get ugly pretty fast, especially if this is what comes up in Finder or Nautilus or Explorer every time I open a window. Unless I misread the PEP, there's only going to be a lib subdirectory. Python packages don't put stuff in other places AFAIK. Maybe. But when I install other software in my homedir, I install it to ~/.local, precisely to avoid what Glyph said about getting the full set of subdirs, and it would be nice for Python to fit into this scheme. On the Mac, the default Finder window is not your home directory but your Desktop, which is a subdirectory thereof with a markedly public name. In fact, OS X has a whole bunch of reserved names in your home directory, and none of them start with a dot. The rule seems to be that if it contains stuff that the user cares about, it doesn't start with a dot. That's not my rule, and it seems that at least Barry and Glyph agree. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On 01:55 am, [EMAIL PROTECTED] wrote: On Thu, May 1, 2008 at 5:03 PM, [EMAIL PROTECTED] wrote: Hi everybody. I apologize for writing yet another lengthy screed about a simple directory naming issue. I feel strongly about it but I encourate anyone who doesn't to simply skip it. First, some background: my strong feelings here are actually based on an experience I had a long time ago when helping someone with some C++ programming homework. They were baffled because when I helped them the programs compiled, but then as soon as they tried it on their own it didn't. The issue was that I had replicated my own autotools-friendly directory structure for them (at the time, ~/bin, ~/include, ~/lib, ~/etc, and so on managed with GNU stow) onto their machine and edited their shell setup to include them appropriately. But, as soon as I was finished, they cleaned up the mess I had left behind, and thereby removed all of their build dependencies. This was on a shared university build server, before the days of linux as a friendly, graphical operating system which encouraged you to look even more frequently at your home directory, so if anything I suspect the likelihood that this is a problem would be worse now. Since cleaning up my own home directory, of course, I find that I appreciate the lack of visual noise in Nautilus et. al. as well. Also, while I obviously think all tools should work this way, I think that Python in particular will attract an audience who is learning to program but not necessarily savvy with arcane nuances of filesystem layout, and it would be best if those details were abstracted. My concern here is for the naive python developer reading installation instructions off of a wiki and trying to get started with Twisted development. Seeing a directory created in your home directory (or, as the case may be, 3 directories, bin, lib, and include) is a bit of a surprise. They don't actually care where the files in their installed library are, as long as they're installed, and they can import them. However, they may care that clicking on the little house icon now shows not Pictures, Movies, etc, but lib (what's a 'lib'?) bin (what's a bin? is that like a box where I throw my stuff?) share (I put my stuff in share, but it's not shared. Wait, I'm supposed to put it in Public?). Briefly, lib is not the only directory participating in this convention; you've also got the full complement of other stuff that might go into an installation like /usr/local. So, while lib might annoy me a little, bin etc games include lib lib32 man sbin share src is going to get ugly pretty fast, especially if this is what comes up in Finder or Nautilus or Explorer every time I open a window. Unless I misread the PEP, there's only going to be a lib subdirectory. Python packages don't put stuff in other places AFAIK. Python packages, at the very least, frequently put stuff in bin (or scripts, I think, on Windows). Not all Python packages are pure- Python packages either; setup.py boasts --install-platlib, --install- headers, --install-data, and --exec-prefix options, which suggests an include, bin, and share directory, at least. I'm sure if I had more time to grovel around I'd find one that installed manpages. Twisted has some, but apparently setup.py doesn't do anything with them, we leave that to the OS packages... Of course, very little of this is handled by the PEP. But even the usage of the name lib implies that the PEP is taking some care to be compatible with an idiom that goes beyond Python itself here, or at least beyond simple Python packages. Even assuming that no Python library ever wanted to install any of these things, there are many Python libraries which are simply wrappers around lower-level libraries, and if I want to perform a per-user install of one of those, I am going to ./configure --prefix=~/something (and by something, I mean .local ;)) and it would be nice to have Python living in the same space. For that matter it'd be nice to get autotools and Ruby and PHP and Perl and Emacs (ad nauseum) all looking at ~/.local as a mirror of /usr, so that I didn't have to write a bunch of shell bootstrap glue to get everything to behave consistently, or learn the new, special names for bits of configuration under ~ that are different from the ones under /usr/local or /etc. I replicate a consistent Python development environment with a ton of bizarre dependencies across something like 15 different OS installations (not to mention a bevy of virtual machines I keep around just for fun), so I think about these issues a lot. Most of these machines are macs and linux boxes, but I do my best on Windows too. FWIW I don't have any idea what the right thing to do is on Windows; .local doesn't particularly make sense, but neither does lib in that context. There's no reasonable guess as to where to put scripts, or dependent shared
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
I stand corrected on a few points. You've convinced me that ~/lib/ is wrong. But I still don't like ~/.local/; not in the last place because it's not any more local than any other dot files or directories. The symmetry with /usr/local/ is pretty weak, and certainly won't help beginning users. As a compromise, I'm okay with ~/Python/. I would like to be able to say that the user explicitly has to set an environment variable in order to benefit from this feature, just like with $PYTHONPATH and $PYTHONSTARTUP. But that might defeat the point of making this easy to use for noobs. On OS X I think we should put this somewhere under ~/Library/. Just put it in a different place than where the Python framework puts its stuff. On Thu, May 1, 2008 at 8:25 PM, [EMAIL PROTECTED] wrote: On 01:55 am, [EMAIL PROTECTED] wrote: On Thu, May 1, 2008 at 5:03 PM, [EMAIL PROTECTED] wrote: Hi everybody. I apologize for writing yet another lengthy screed about a simple directory naming issue. I feel strongly about it but I encourate anyone who doesn't to simply skip it. First, some background: my strong feelings here are actually based on an experience I had a long time ago when helping someone with some C++ programming homework. They were baffled because when I helped them the programs compiled, but then as soon as they tried it on their own it didn't. The issue was that I had replicated my own autotools-friendly directory structure for them (at the time, ~/bin, ~/include, ~/lib, ~/etc, and so on managed with GNU stow) onto their machine and edited their shell setup to include them appropriately. But, as soon as I was finished, they cleaned up the mess I had left behind, and thereby removed all of their build dependencies. This was on a shared university build server, before the days of linux as a friendly, graphical operating system which encouraged you to look even more frequently at your home directory, so if anything I suspect the likelihood that this is a problem would be worse now. Since cleaning up my own home directory, of course, I find that I appreciate the lack of visual noise in Nautilus et. al. as well. Also, while I obviously think all tools should work this way, I think that Python in particular will attract an audience who is learning to program but not necessarily savvy with arcane nuances of filesystem layout, and it would be best if those details were abstracted. My concern here is for the naive python developer reading installation instructions off of a wiki and trying to get started with Twisted development. Seeing a directory created in your home directory (or, as the case may be, 3 directories, bin, lib, and include) is a bit of a surprise. They don't actually care where the files in their installed library are, as long as they're installed, and they can import them. However, they may care that clicking on the little house icon now shows not Pictures, Movies, etc, but lib (what's a 'lib'?) bin (what's a bin? is that like a box where I throw my stuff?) share (I put my stuff in share, but it's not shared. Wait, I'm supposed to put it in Public?). Briefly, lib is not the only directory participating in this convention; you've also got the full complement of other stuff that might go into an installation like /usr/local. So, while lib might annoy me a little, bin etc games include lib lib32 man sbin share src is going to get ugly pretty fast, especially if this is what comes up in Finder or Nautilus or Explorer every time I open a window. Unless I misread the PEP, there's only going to be a lib subdirectory. Python packages don't put stuff in other places AFAIK. Python packages, at the very least, frequently put stuff in bin (or scripts, I think, on Windows). Not all Python packages are pure- Python packages either; setup.py boasts --install-platlib, --install- headers, --install-data, and --exec-prefix options, which suggests an include, bin, and share directory, at least. I'm sure if I had more time to grovel around I'd find one that installed manpages. Twisted has some, but apparently setup.py doesn't do anything with them, we leave that to the OS packages... Of course, very little of this is handled by the PEP. But even the usage of the name lib implies that the PEP is taking some care to be compatible with an idiom that goes beyond Python itself here, or at least beyond simple Python packages. Even assuming that no Python library ever wanted to install any of these things, there are many Python libraries which are simply wrappers around lower-level libraries, and if I want to perform a per-user install of one of those, I am going to ./configure --prefix=~/something (and by something, I mean .local ;)) and it would be nice to have Python living in the same space. For that matter it'd be nice to get autotools and Ruby and PHP and Perl and Emacs (ad nauseum) all looking at ~/.local
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On 03:49 am, [EMAIL PROTECTED] wrote: I stand corrected on a few points. You've convinced me that ~/lib/ is wrong. But I still don't like ~/.local/; not in the last place because it's not any more local than any other dot files or directories. The symmetry with /usr/local/ is pretty weak, and certainly won't help beginning users. Why do you say the symmetry is weak? The name might not be that evocative, but the main thrust of what I'm saying is that ~/.x should be an autotools-style directory layout. The symmetry I suggest is in exactly that sense; that's what /usr/local is. I don't actually care what x is, except I (and many others) already use local for that value, and the more software that honors it, the better. GNU stow (arguably the king of per-user installation management) suggests ~/local as an autotools --prefix target; the free desktop project implicitly suggests ~/.local (by suggesting ~/.local/share is a place to put the same files that would normally be searched for in /usr/share and /usr/local/share). So the word local is just floating around in this meme space; I don't like the word that much, but I don't see that there's a different one which more clearly evokes the concept either. I originally used ~/UNIX and then ~/.unix, but switched to .local when I noticed other folks doing it. One I've actually seen mentioned a few times is ~/.nix-config, which I certainly don't think is any better. It would help beginning users if ~/.local/bin and ~/.local/lib were honored by the system. I, and other adherents of this idea that it would be nice if users could install source without admin privs, have been suggesting that to distro guys when I (we) can, and I figure in a few years, somebody might bite. If that happens, it will start being *easier* to build stuff from source into a separated location than to need root, stomp on the system, and inevitably break some stuff. Agitating for ~/Python/Platform/Libraries on $LD_LIBRARY_PATH (or equivalent) is a lot harder to do with a straight face. This is the reason I'm bothering to spill so many pixels on this topic; I think it would be great if Python were the first real adopter of this convention, and once *one* project has really gone full bore, each subsequent one is progressively easier to convince. However, if you've made up your mind on ~/Python, I think I've more than made my case at this point, so I'll stop cluttering up the lists :). (By the way, for what it's worth: I _hate_ the bin/lib/etc/man/src/include naming convention mess, but it's a mess which is programmatically honored in like a hundred billion lines of code. This is why I want it supported, but hidden ;).) As a compromise, I'm okay with ~/Python/. I would like to be able to say that the user explicitly has to set an environment variable in order to benefit from this feature, just like with $PYTHONPATH and $PYTHONSTARTUP. But that might defeat the point of making this easy to use for noobs. Is there another point? It seems to me that this change is entirely about shared conventions and works by default behavior. If you are going to set an environment variable, set PYTHONPATH; it's already much more flexible. ~/Python opens up some new problems though, although perhaps they are trivially resolved: how should this interoperate with distutils? 'Just make python setup.py --user do what python setup.py --prefix ~/.local would do' is pretty straightforward, but ~/Python would need a new convention. Should ~/Python have a ~/Python/Scripts directory that one could add to $PATH? A ~/Python/Platform directory, for includes, libraries, other random junk like manpages or HTML docs? ~/Python/2.6/lib, or ~/Python2.6/lib? To be fair, a separate, and purpose-designed Python directory layout might also make certain things neater. For example one could support parallel installation with Python2.6 (or Python/2.6) by giving each a 'lib' and 'bin' directory, and always having the scripts in the 2.6/bin dir invoke the 2.6 interpreter, rather than having separated space for libraries but having to mangle the names of scripts (twistd8.0-py2.6). I'd still prefer compatibility-by-convention with other tools, languages, etc, though. In the long term, if everyone followed suit on ~/.local, that would be great. But I don't want a ~/Python, ~/Java, ~/Ruby, ~/PHP, ~/Perl, ~/OCaml and ~/Erlang and a $PATH as long as my arm just so I can run a few applications without system-installing them. On OS X I think we should put this somewhere under ~/Library/. Just put it in a different place than where the Python framework puts its stuff. Isn't the whole point that it should be the same place? Under current Python releases, OS X already has this functionality via ~/Library/Python/2.5/site-packages. Also, I'd strongly suggest supporting both ~/Library (although the existing location seems fine to me) *and* whatever the default is
