At 8:42 PM +0100 12/2/06, Martin v. Löwis wrote:
Jan Claeys schrieb:
Like I said, it's possible to split Python without making things
complicated for newbies.
You may have that said, but I don't believe its truth. For example,
most distributions won't include Tkinter in the standard Python
Hi Martin,
On Sun, Dec 03, 2006 at 07:56:34PM +0100, Martin v. L?wis wrote:
People use distutils for other purposes today as well, and these
purposes might be supported now.
OK, makes some kind of sense. I suppose (as you point out in another
thread) that the issue is that distros generally
Hi Andrew,
On Fri, Dec 01, 2006 at 03:27:09PM +1100, Andrew Bennetts wrote:
In both the current Debian and Ubuntu releases, the python2.4 binary package
includes distutils.
Ah, distutils are distributed in the base package now, but not the
'config' subdirectory of a standard library's normal
Armin Rigo schrieb:
Ah, distutils are distributed in the base package now, but not the
'config' subdirectory of a standard library's normal installation, which
makes distutils a bit useless.
I should go and file a bug, I guess. The reason why I did not do it so
far, is that the fact that
Hi Andrew,
On Fri, Dec 01, 2006 at 03:27:09PM +1100, Andrew Bennetts wrote:
In both the current Debian and Ubuntu releases, the python2.4 binary package
includes distutils.
Ah, good. This must be a relatively recent change. I'm not a Debian
user, but merely a user that happens to have to use
Op vrijdag 01-12-2006 om 00:16 uur [tijdzone +], schreef Steve
Holden:
Jan Claeys wrote:
[...]
Probably the Debian maintainers could have named packages differently to
make things less confusing for newbies (e.g. by having the 'pythonX.Y'
packages being meta-packages that depend on all
Armin Rigo a écrit :
Now I only have to hope that 2.4.4 makes its way out of 'unstable' soon.
As far as I can tell sysadmins installing the current 'testing' would
still be getting a Python 2.4.3, not modern enough to cope with the
arithmetic overflow issues introduced by the cutting-edge GCC
Jan Claeys schrieb:
Like I said, it's possible to split Python without making things
complicated for newbies.
You may have that said, but I don't believe its truth. For example,
most distributions won't include Tkinter in the standard Python
installation: Tkinter depends on _tkinter depends on
Martin v. Löwis wrote:
Like I said, it's possible to split Python without making things
complicated for newbies.
You may have that said, but I don't believe its truth. For example,
most distributions won't include Tkinter in the standard Python
installation: Tkinter depends on _tkinter
Fredrik Lundh schrieb:
maybe we could just ask distributors to prepare a page that describes
what portions of the standard distribution they do include, and in what
packages they've put the various components, and link to those from the
library reference and/or the wiki or FAQ? is there
Fair enough.
Robin
On 30/11/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
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
Greg Ewing wrote:
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
Barry Warsaw wrote:
On the easy_install naming front, how about layegg?
I think I once proposed hatch but that may not be quite the right
word (where's Ken M when you need him? :).
I really don't like all these cute names, simply because they are
obscure. Names that only make sense once
On Thursday, November 30, 2006, at 03:49PM, Talin [EMAIL PROTECTED] wrote:
Barry Warsaw wrote:
On the easy_install naming front, how about layegg?
I think I once proposed hatch but that may not be quite the right
word (where's Ken M when you need him? :).
I really don't like all these
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 30, 2006, at 9:40 AM, Talin wrote:
Greg Ewing wrote:
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
Perhaps pyinstall?
Bill
On Nov 30, 2006, at 9:49 AM, Talin wrote:
I really don't like all these cute names, simply because they are
obscure. Names that only make sense once you've gotten the joke may
be self-gratifying but not good HCI.
Warsaw's Fifth Law :)
How about:
On 05:37 pm, [EMAIL PROTECTED] wrote:
Perhaps pyinstall?
Keep in mind that Python packages will still generally be *system*-installed
with other tools, like dpkg (or apt) and rpm, on systems which have them. The
name of the packaging system we're talking about is called either eggs or
Op woensdag 29-11-2006 om 12:23 uur [tijdzone +0100], schreef Armin
Rigo:
I could not agree more. Nowadays, whenever I get an account on a new
Linux machine, the first thing I have to do is reinstall Python
correctly in my home dir because the system Python lacks distutils.
Wasteful. (There
Jan Claeys wrote:
Op woensdag 29-11-2006 om 12:23 uur [tijdzone +0100], schreef Armin
Rigo:
I could not agree more. Nowadays, whenever I get an account on a new
Linux machine, the first thing I have to do is reinstall Python
correctly in my home dir because the system Python lacks distutils.
On 11/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
The major advantage ~/.local has for *nix systems is the ability to have a
parallel *bin* directory, which provides the user one location to set their
$PATH to, so that installed scripts work as expected, rather than having to
edit a
At 02:46 PM 11/30/2006 -0800, Mike Orr wrote:
Speaking of Virtual Python [1], I've heard some people recommending it
as a general solution to the this library breaks that other
application problem and this app needs a different version of X
library than that other app does.
It was actually
Op donderdag 30-11-2006 om 21:48 uur [tijdzone +], schreef Steve
Holden:
I think the point is that some distros (Debian is the one that springs
to mind most readily, but I'm not a distro archivist) require a separate
install for distutils even though it's been a part of the standard
Barry Warsaw wrote:
When I switched to OS X for most of my desktops, I had several
collisions in this namespace.
I think on MacOSX you have to consider that it's really
~/Documents and the like that are *your* namespaces,
rather than the top level of your home directory.
Also, I think
Op vrijdag 01-12-2006 om 12:44 uur [tijdzone +1300], schreef Greg Ewing:
With ~/.local, you're hiding the fact that the applications
or libraries or whatever are even there in the first
place. You've got all this disk space being used up,
but no way of seeing where or by what, and no
obvious
Jan Claeys wrote:
[...]
Probably the Debian maintainers could have named packages differently to
make things less confusing for newbies (e.g. by having the 'pythonX.Y'
packages being meta-packages that depend on all binary packages built
from the upstream source package), but that doesn't mean
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 30, 2006, at 6:44 PM, Greg Ewing wrote:
Barry Warsaw wrote:
When I switched to OS X for most of my desktops, I had several
collisions in this namespace.
I think on MacOSX you have to consider that it's really
~/Documents and the like
On Fri, Dec 01, 2006 at 12:42:42AM +0100, Jan Claeys wrote:
Op donderdag 30-11-2006 om 21:48 uur [tijdzone +], schreef Steve
Holden:
I think the point is that some distros (Debian is the one that springs
to mind most readily, but I'm not a distro archivist) require a separate
install
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.
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
-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
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
Actually, I meant that (among other things) it should be clarified that
it's alright to e.g. put .pyc and data files inside Python library
directories, and NOT okay to split them up.
Phillip, Just to be clear: I understand you are not in favour of
re-packaging data from python projects
On Tuesday 28 November 2006 23:19, Robin Bryce wrote:
python2.4 profile (pstats) etc, was removed due to licensing
issues rather than FHS. Should not be an issue for python2.5 but
what, in general, can a vendor do except break python if their
licensing policy cant accommodate all of pythons
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 28, 2006, at 8:53 AM, Anthony Baxter wrote:
(The only other packaging thing like this that I'm aware of is
python-minimal in Ubuntu. This is done for installation purposes
and wacky dependency issues that occur when a fair chunk of the O/S
Robin Bryce schrieb:
python2.4 profile (pstats) etc, was removed due to licensing issues
rather than FHS. Should not be an issue for python2.5 but what, in
general, can a vendor do except break python if their licensing policy
cant accommodate all of pythons batteries ?
If some vendor has a
On 11/28/06, Barry Warsaw [EMAIL PROTECTED] wrote:
For distros like Gentoo or Ubuntu that rely heavily on their
own system Python for the OS to work properly, I'm quite loathe to
install Cheeseshop packages into the system site-packages. I've had
Gentoo break occasionally when I did this for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 28, 2006, at 2:41 PM, Mike Orr wrote:
On 11/28/06, Barry Warsaw [EMAIL PROTECTED] wrote:
For distros like Gentoo or Ubuntu that rely heavily on their
own system Python for the OS to work properly, I'm quite loathe to
install Cheeseshop
At 01:05 PM 11/28/2006 -0800, 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 28, 2006, at 4:05 PM, 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
I question whether a distro built on Python can even afford to allow
3rd party packages to be installed in their system's site-packages.
Maybe Python needs to extend its system-centric view of site-packages
with an application-centric and/or user-centric view of extensions?
Agreed,
On 11:45 pm, [EMAIL PROTECTED] wrote:
I keep thinking I'd like to treat the OS as just another application,
so that there's nothing special about it and the same infrastructure
could be used for other applications with lots of entry level scripts.
I agree. The motivation here is that the OS
At 06:41 PM 11/28/2006 -0500, Barry Warsaw wrote:
On Nov 28, 2006, at 4:19 PM, Phillip J. Eby wrote:
At 01:05 PM 11/28/2006 -0800, 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 28, 2006, at 4:19 PM, Phillip J. Eby wrote:
At 01:05 PM 11/28/2006 -0800, 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 28, 2006, at 7:10 PM, Phillip J. Eby wrote:
Well, you can always use setuptools, which generates script
wrappers that import the desired module and call a function, after
first setting up sys.path. :)
That's so 21st Century! Where
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phillip J. Eby napsal(a):
Just a suggestion, but one issue that I think needs addressing is the FHS
language that leads some Linux distros to believe that they should change
Python's normal installation layout (sometimes in bizarre ways) (...)
At 02:38 PM 11/27/2006 +0100, Jan Matejek wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phillip J. Eby napsal(a):
Just a suggestion, but one issue that I think needs addressing is the FHS
language that leads some Linux distros to believe that they should change
Python's normal
Phillip J. Eby schrieb:
Actually, I meant that (among other things) it should be clarified that
it's alright to e.g. put .pyc and data files inside Python library
directories, and NOT okay to split them up.
My gut feeling is that this is out of scope for the LSB. The LSB would
only specify
Jan Matejek schrieb:
+1 on that. There should be a clear (and clearly presented) idea of how
Python is supposed to be laid out in the distribution-provided /usr
hierarchy. And it would be nice if this idea complied to FHS.
The LSB refers to the FHS, so it is clear that LSB support for Python
Hi everyone,
Guido van Rossum suggested I send this email here.
I'm CTO of the Free Standards Group and chair of the Linux Standard
Base (LSB), the interoperability standard for the Linux distributions.
We're wanting to add Python to the next version of the LSB (LSB 3.2) [1]
and are looking for
Ian Murdock schrieb:
I'm CTO of the Free Standards Group and chair of the Linux Standard
Base (LSB), the interoperability standard for the Linux distributions.
We're wanting to add Python to the next version of the LSB (LSB 3.2) [1]
and are looking for someone (or, better, a few folks) in the
On Sun, Nov 26, 2006, Martin v. L?wis wrote:
I wrote to Ian that I would be interested; participating in the meeting
in Berlin is quite convenient. I can try to keep python-dev updated.
Please do -- it's not something I have a lot of cycles for but am
interested in.
--
Aahz ([EMAIL
At 11:09 AM 11/22/2006 -0500, Ian Murdock wrote:
The first question we have to answer is: What does it mean to add
Python to the LSB? Is it enough to say that Python is present
at a certain version and above, or do we need to do more than that
(e.g., many distros ship numerous Python add-ons which
Excellent! Like Aahz, I have no cycles, but I think it's a worthy goal.
--Guido
On 11/26/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Ian Murdock schrieb:
I'm CTO of the Free Standards Group and chair of the Linux Standard
Base (LSB), the interoperability standard for the Linux
67 matches
Mail list logo
