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
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
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 the
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
>
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:
> 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.
setuptool
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 t
-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 h
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.
>
> I'd rather have to set/uncomment an environment variable on my system
> than having 100 "normal" users break their systems accidentally... ;-
-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 HOM
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
Python-
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 exp
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 i
-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:
> 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
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 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 scri
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:
> 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
tha
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 $HOME/
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 refere
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
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 distribut
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 th
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 site-pack
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-De
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 famil
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.
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
http://mail.python.org/mailma
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
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 subm
-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", "
[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 spe
On 06:37 pm, [EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] wrote:
>>I think the relevant link to change here would be ~/.local.
>>
>>I have personally been using the ~/.local convention for a while, and
>>I
>>believe ~/.local/bin is where scripts should go. Python is not the
>>only
>>thing that ca
[EMAIL PROTECTED] wrote:
> I think the relevant link to change here would be ~/.local.
>
> I have personally been using the ~/.local convention for a while, and I
> believe ~/.local/bin is where scripts should go. Python is not the only
> thing that can be locally installed, and the fact that i
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
Christian Heimes wrote:
> [...]
> PEP: XXX
> Title: Per user site-packages directory
> Version: $Revision$
> Last-Modified: $Date$
> Author: Christian Heimes
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 11-Jan-2008
> Python-Version: 2.6, 3.0
> Post-History:
> [..
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:
http://mail.python.org/mailman/options/python-dev/archive%40mail-arc
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 importe
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
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 become
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.
>
> Additio
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 packa
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
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: Christi
45 matches
Mail list logo
