On 28-nov-2006, at 22:05, Guido van Rossum wrote:
On 11/28/06, Barry Warsaw [EMAIL PROTECTED] wrote:
There's a related issue that may or may not be in scope for this
thread. For distros like Gentoo or Ubuntu that rely heavily on their
own system Python for the OS to work properly, I'm quite
On 09:34 am, [EMAIL PROTECTED] wrote:
There's another standard place that is searched on MacOS: a per-user
package directory ~/Library/Python/2.5/site-packages (the name site-
packages is a misnomer, really). Standardising something here is
less important than for vendor-packages (as the effect
Hi Anthony,
On Wed, Nov 29, 2006 at 12:53:14AM +1100, Anthony Baxter wrote:
python2.4 distutils is excluded by default.
I still have no idea why this was one - I was also one of the people
who jumped up and down asking Debian/Ubuntu to fix this idiotic
decision.
I could not agree more.
This seems a bug. In revision 36714 by Raymond Hettinger, the
restriction that locals be a dict was relaxed to allow any mapping.
On 11/29/06, Daniel Trstenjak [EMAIL PROTECTED] wrote:
Hi all,
I would like to know the definition of the 'locals' object given to
PyEval_EvalCode. Has 'locals'
Guido van Rossum schrieb:
I wonder if would help if we were to add a vendor-packages directory
where distros can put their own selection of 3rd party stuff they
depend on, to be searched before site-packages, and a command-line
switch that ignores site-package but still searches
Hi,
On Wed, Nov 29, 2006 at 07:39:25AM -0800, Guido van Rossum wrote:
This seems a bug. In revision 36714 by Raymond Hettinger, the
restriction that locals be a dict was relaxed to allow any mapping.
Mea culpa, I thought I reviewed this patch at the time.
Fixed in r52862-52863.
A bientot,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 29, 2006, at 5:18 AM, [EMAIL PROTECTED] wrote:
Yes, let's do that, please. I've long been annoyed that site.py
sets up a local user installation directory, a very useful feature,
but _only_ on OS X. I've long since promoted my
Barry Warsaw wrote:
I'm not sure I like ~/.local though
- -- it seems counter to the app-specific dot-file approach old
schoolers like me are used to.
Problems with that are starting to show, though.
There's a particular Unix account that I've had for
quite a number of years, accumulating
[Guido van Rossum]
This seems a bug. In revision 36714 by Raymond Hettinger,
the restriction that locals be a dict was relaxed to allow
any mapping.
[Armin Rigo]
Mea culpa, I thought I reviewed this patch at the time.
Fixed in r52862-52863.
Armin, thanks for the check-ins. Daniel, thanks
On 28/11/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
I personally agree that Linux standards should specify a standard
layout for a Python installation, and that it should be the one that
make install generates (perhaps after make install is adjusted).
Whether or not it is the *LSB* that
On 29 Nov, 11:49 pm, [EMAIL PROTECTED] wrote:
On Nov 29, 2006, at 5:18 AM, [EMAIL PROTECTED] wrote:
I'd suggest using ~/.local/lib/pythonX.X/site-packages for the
official UNIX installation location, ...
+1 from me also for the concept. I'm not sure I like ~/.local though
- -- it seems
On 12:34 am, [EMAIL PROTECTED] wrote:
The whole concept of hidden files seems ill-
considered to me, anyway. It's too easy to forget
that they're there. Putting infrequently-referenced
stuff in a non-hidden location such as ~/local
seems just as good and less magical to me.
Something like
On Wednesday 29 November 2006 22:20, [EMAIL PROTECTED] wrote:
GNOME et. al. aren't promoting the concept too hard. It's just the first
convention I came across. (Pardon the lack of references here, but it's
very hard to google for ~/.local - I just know that I was looking for a
At 03:20 AM 11/30/2006 +, [EMAIL PROTECTED] wrote:
One of the things that combinator hacks is where distutils thinks it
should install to - when *I* type python setup.py install nothing tries
to insert itself into system directories (those are for Ubuntu, not me) -
~/.local is the *default*
At 06:49 PM 11/29/2006 -0500, Barry Warsaw wrote:
What might be nice would be to build a little more
infrastructure into Python to support eggs, by say adding a default
PEP 302 style importer that knows how to search for eggs in
'nests' (a directory containing a bunch of eggs).
If you have
On 04:11 am, [EMAIL PROTECTED] wrote:
On Wednesday 29 November 2006 22:20, [EMAIL PROTECTED] wrote:
GNOME et. al. aren't promoting the concept too hard. It's just the first
convention I came across. (Pardon the lack of references here, but it's
very hard to google for ~/.local - I just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 29, 2006, at 10:20 PM, [EMAIL PROTECTED] wrote:
Another nice feature there is that it uses a pre-existing layout
convention (bin lib share etc ...) rather than attempting to build
a new one, so the only thing that has to change about
On 04:36 am, [EMAIL PROTECTED] wrote:
easy_install uses the standard distutils configuration system, which means
that you can do e.g.
Hmm. I thought I knew quite a lot about distutils, but this particular nugget
had evaded me. Thanks! I see that it's mentioned in the documentation, but I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 29, 2006, at 11:45 PM, Phillip J. Eby wrote:
[Phillip describes a bunch of things I didn't know about setuptools]
As is often the case, maybe everything I want is already there and
I've just been looking in the wrong places. :) Thanks!
At 05:10 AM 11/30/2006 +, [EMAIL PROTECTED] wrote:
On 04:36 am, [EMAIL PROTECTED] wrote:
easy_install uses the standard distutils configuration system, which means
that you can do e.g.
Hmm. I thought I knew quite a lot about distutils, but this particular
nugget had evaded me. Thanks!
Robin Bryce schrieb:
Yes, especially with the regard to the level you pitch for LSB. I
would go as far as to say that if this contract in spirit is broken
by vendor repackaging they should:
* Call the binaries something else because it is NOT python any more.
* Setup the installation layout
21 matches
Mail list logo
