I don't really understand what all this has to do with per user
site-packages.
Note that the motivation for having per user site-packages
was to:
* address a common request by Python extension package users,
* get rid off the hackery done by setuptools in order
to provide this.
As such
At 04:42 PM 1/22/2008 +0100, M.-A. Lemburg wrote:
I don't really understand what all this has to do with per user
site-packages.
Note that the motivation for having per user site-packages
was to:
* address a common request by Python extension package users,
* get rid off the hackery done by
M.-A. Lemburg wrote:
I don't really understand what all this has to do with per user
site-packages.
Note that the motivation for having per user site-packages
was to:
* address a common request by Python extension package users,
* get rid off the hackery done by setuptools in order
-On [20080120 19:34], Christian Heimes ([EMAIL PROTECTED]) wrote:
Most Python developers should the meaning of ~. Should I replace ~
with $HOME for those who don't have as much experience with Unix as we?
The problem is that ~ is an expansion character. It expands the contents of
$HOME. If HOME
-On [20080116 07:15], Martin v. Löwis ([EMAIL PROTECTED]) wrote:
I don't understand why they *have* to do that. I can believe they do
that as they don't know better - but why can't they use the Python
interpreter already available on the system, and just install additional
packages in their home
Martin v. Löwis wrote:
Right now Python faces a lot of problems in the webhosting world because it's
tedious to set up and maintain for the webhosting user since they often have
to compile and install their own Python in their home directory.
I don't understand why they *have* to do that. I
Steve Holden wrote:
Maybe once we get easy_install as a part of the core (so there's no need
to find and run ez_setup.py to start with) things will start to improve.
This is an issue the whole developer community needs to take seriously
if we are interested in increasing take-up.
setuptools
Christian Heimes wrote:
Steve Holden wrote:
Maybe once we get easy_install as a part of the core (so there's no need
to find and run ez_setup.py to start with) things will start to improve.
This is an issue the whole developer community needs to take seriously
if we are interested in
Steve Holden wrote:
Christian Heimes wrote:
Steve Holden wrote:
Maybe once we get easy_install as a part of the core (so there's no need
to find and run ez_setup.py to start with) things will start to improve.
This is an issue the whole developer community needs to take seriously
if we are
Op zondag 13-01-2008 om 10:45 uur [tijdzone +0100], schreef Christian
Heimes:
Gregory P. Smith wrote:
My main suggestion was going to be the ability to turn it off as you already
mentioned. However, please consider leaving it off by default to avoid
problems for installed python scripts
Op zaterdag 12-01-2008 om 00:27 uur [tijdzone +0100], schreef Christian
Heimes:
Specification
=
[...]
user configuration directory
Usually the parent directory of the user site directory. It's meant
for Python version specific data like config files.
Windows:
Jan Claeys wrote:
What do you mean by configuration directory? IMHO configuration files
on linux/unix should go into ~/.python2.6 or ~/.config/python2.6 or
something like that?
It's already renamed in the PEP:
http://www.python.org/dev/peps/pep-0370/#specification
Christian
-On [20080116 07:15], Oleg Broytmann ([EMAIL PROTECTED]) wrote:
The site only mentions $HOME/.local/share, there is no $HOME/.local/bin
at the site.
As was mentioned earlier in the thread. Only $HOME/.local/share was in the
Free Desktop specification. The bin is something that got introduced
Jan Claeys wrote:
There should be a way for distro developers to make sure the users local
'site-packages' is *not* used when running those tools.
There is an option. Those tools should use the -E and -s argument:
#!/usr/bin/env python -E -s
Christian
Op zondag 20-01-2008 om 18:01 uur [tijdzone +0100], schreef Christian
Heimes:
Jan Claeys wrote:
What do you mean by configuration directory? IMHO configuration files
on linux/unix should go into ~/.python2.6 or ~/.config/python2.6 or
something like that?
It's already renamed in the PEP:
Jeroen Ruigrok van der Werven wrote:
Pendantic note: ~ is an expansion character, the correct variable to talk
about is HOME (see IEEE Std 1003.1, 2004 section 2.5.3 and 2.6.1).
Most Python developers should the meaning of ~. Should I replace ~
with $HOME for those who don't have as much
Jan Claeys wrote:
So this is stuff that should never be changed by the user?
~/.local/lib/python2.6 has the same semantics as
/usr/local/lib/python2.6 except it's a per user directory and not per
machine.
Christian
___
Python-Dev mailing list
Jeroen Ruigrok van der Werven wrote:
One thing I miss in this PEP and discussion is the point of view from a
webhosting company and webhosting user.
If the webhoster upgrades his hosting software and Python get updated by a
revision (say 2.5 to 2.6) this would in the current case mean that
On Mon, Jan 14, 2008 at 11:41:47PM +, Jon Ribbens wrote:
It makes sense, but personally I have never heard before of ~/.local.
Whereas ~/bin is something I am quite familiar with.
Me too. python-dev is the only place I have heard of ~/.local. I have
been using Linux (different
On Jan 15, 2008 6:24 AM, Oleg Broytmann [EMAIL PROTECTED] wrote:
On Mon, Jan 14, 2008 at 11:41:47PM +, Jon Ribbens wrote:
It makes sense, but personally I have never heard before of ~/.local.
Whereas ~/bin is something I am quite familiar with.
Me too. python-dev is the only place I
On Tue, Jan 15, 2008 at 01:21:46PM +0100, Christian Heimes wrote:
It took me a while to find a reference to .local. It's part of the
FreeDesktop.Org standards:
http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
The site only mentions $HOME/.local/share, there is no
Kevin Jacobs [EMAIL PROTECTED] wrote:
Never heard of it either, would be completely baffled if caught unawares by
it in the wild. Has anyone consulted with the LSB or a cross-platform
filesystem layout guide to see what the recommended best-practice is?
It took me a while to find a reference
Right now Python faces a lot of problems in the webhosting world because it's
tedious to set up and maintain for the webhosting user since they often have
to compile and install their own Python in their home directory.
I don't understand why they *have* to do that. I can believe they do
that
Christian Heimes wrote:
[...]
PEP: XXX
Title: Per user site-packages directory
Version: $Revision$
Last-Modified: $Date$
Author: Christian Heimes christian(at)cheimes(dot)de
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Jan-2008
Python-Version: 2.6, 3.0
On 12:08 pm, [EMAIL PROTECTED] wrote:
So if I'm using the --user option, where would scripts be installed?
Would this be:
Windows: %APPDATA%/Python/Python26/bin
Mac: ~/Library/Python/2.6/bin
Unix: ~/.local/lib/python2.6/bin
I'd like to be able to switch between several versions of my user
[EMAIL PROTECTED] wrote:
the standard directory? according to what? commented-out examples in
some linux distribution?
Yes ... :/
I should be more carefully when I use the word standard.
But, now that I've told you what I think in more detail, unless you like
my ideas and have specific
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 14, 2008, at 2:13 PM, [EMAIL PROTECTED] wrote:
~/bin comes from the convention of ./configure --prefix=$HOME, as
autoconf suggests. This means users must have visible directories in
their home folder named (among other things) bin, share,
Barry Warsaw wrote:
I feel pretty strongly that ~/bin should *not* be used. It makes
sense to me that ~/.local would mirror /usr/local.
Two votes for ~/.local/bin and one undecided PEP author ... I'm changing
the code to ~/.local/bin and I'm adding a new section to the PEP.
Can I just
On Jan 14, 2008 12:27 PM, Christian Heimes [EMAIL PROTECTED] wrote:
Barry Warsaw wrote:
I feel pretty strongly that ~/bin should *not* be used. It makes
sense to me that ~/.local would mirror /usr/local.
Two votes for ~/.local/bin and one undecided PEP author ... I'm changing
the code to
The PEP is now available at http://www.python.org/dev/peps/pep-0370/.
The reference implementation is in svn, too:
svn+ssh://[EMAIL PROTECTED]/sandbox/trunk/pep370
Christian
___
Python-Dev mailing list
Python-Dev@python.org
On 2008-01-14 22:23, Christian Heimes wrote:
The PEP is now available at http://www.python.org/dev/peps/pep-0370/.
The reference implementation is in svn, too:
svn+ssh://[EMAIL PROTECTED]/sandbox/trunk/pep370
Thanks for the effort, Christian. Much appreciated.
Regarding the recent ~/bin vs.
On Mon, Jan 14, 2008 at 03:07:20PM -0500, Barry Warsaw wrote:
I feel pretty strongly that ~/bin should *not* be used. It makes
sense to me that ~/.local would mirror /usr/local.
It makes sense, but personally I have never heard before of ~/.local.
Whereas ~/bin is something I am quite
On Jan 14, 2008 6:41 PM, Jon Ribbens [EMAIL PROTECTED] wrote:
It makes sense, but personally I have never heard before of ~/.local.
Whereas ~/bin is something I am quite familiar with.
*raises hand* I have one, fwiw.
--
Cheers,
Leif
___
Python-Dev
One thing I miss in this PEP and discussion is the point of view from a
webhosting company and webhosting user.
If the webhoster upgrades his hosting software and Python get updated by a
revision (say 2.5 to 2.6) this would in the current case mean that the
webhosting user using per-user
Gregory P. Smith wrote:
My main suggestion was going to be the ability to turn it off as you already
mentioned. However, please consider leaving it off by default to avoid
problems for installed python scripts importing user supplied code. For
shared hosting environments where this becomes
On 1/13/08, Christian Heimes [EMAIL PROTECTED] wrote:
Gregory P. Smith wrote:
My main suggestion was going to be the ability to turn it off as you
already
mentioned. However, please consider leaving it off by default to avoid
problems for installed python scripts importing user supplied
Gregory P. Smith wrote:
I also tried to check if os.stat(__main__.__file__).st_uid ==
os.getuid() but the real __main__ is not available in site.py. It's
loaded and assigned much later.
Is sys.argv[0] available at that point?
No, it's not available, too. The 'site' module is imported by
I've uploaded a new patch:
http://bugs.python.org/issue1799
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Christian Heimes wrote:
MA Lemburg has suggested a per user site-packages directory in the
pkgutil, pkg_resource and Python 3.0 name space packages thread. I've
written a short PEP about it for Python 2.6 and 3.0.
Addition:
An user has requested a new option to suppress the user site packages
On 1/12/08, Christian Heimes [EMAIL PROTECTED] wrote:
Christian Heimes wrote:
MA Lemburg has suggested a per user site-packages directory in the
pkgutil, pkg_resource and Python 3.0 name space packages thread. I've
written a short PEP about it for Python 2.6 and 3.0.
Addition:
An user
MA Lemburg has suggested a per user site-packages directory in the
pkgutil, pkg_resource and Python 3.0 name space packages thread. I've
written a short PEP about it for Python 2.6 and 3.0.
PEP: XXX
Title: Per user site-packages directory
Version: $Revision$
Last-Modified: $Date$
Author:
I can't comment on the implementation details, but +1 for the idea. I
think this feature will be very useful in a shared hosting
environment.
-- Alexandre
On Jan 11, 2008 6:27 PM, Christian Heimes [EMAIL PROTECTED] wrote:
PEP: XXX
Title: Per user site-packages directory
Version: $Revision$
42 matches
Mail list logo
