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" Py
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 generall
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 t
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 norma
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
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 _tk
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
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
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
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
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 th
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
> >
-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
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 m
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
> obvi
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 MacO
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
>
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
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
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 dis
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. (The
At 06:02 PM 11/30/2006 +, [EMAIL PROTECTED] wrote:
>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 packag
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
"se
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 :)
>
> > H
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 :)
>
-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 a
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 do
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
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
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
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. T
-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! I'l
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 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: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
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 set
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 *def
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
> conv
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 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 s
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 *L
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, accumulatin
-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 perso
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 vendor-pack
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 m
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 eff
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
-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
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
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.
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"
> 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?
Agree
-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
>>
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 properl
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 loathe to
> install Cheeseshop packages into the
-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 Cheese
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
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
-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/
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
> 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 (proj
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
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
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 norm
-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) (...)
>
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 dis
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
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 PROTEC
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 t
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 s
70 matches
Mail list logo
