Re: [Python-Dev] trunk buildbot status

[Eric Smith]

Trent Nelson wrote:
> I'd recommend cd'ing to your trunk root directory and running 
> Tool\buildbot\build.bat from there -- it'll automatically check out all the 
> dependencies and build via command line with vcbuild (building via Visual 
> Studio usually always Does The Right Thing, command line builds often take a 
> bit more coercing).

Okay, that's extremely helpful.  With that (and installing nasmw.exe), a 
trunk checkout builds correctly and passes all tests (although skipping 
test_tcl) on my box.  As I said, it's XP x86 with 2008 Express Edition only.

Let me know if I can provide any other information.  Unfortunately I 
don't have access to this box during the work day (EDT), and I'm leaving 
for vacation tomorrow (Friday).  But I'll help as best I can.

Eric.

> 
> 
> From: Eric Smith [EMAIL PROTECTED]
> Sent: 19 March 2008 20:49
> To: Trent Nelson
> Cc: python-dev@python.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL 
> PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [Python-Dev] trunk buildbot status
> 
> Trent Nelson wrote:
>> Quick update on the status of the trunk buildbots:
>>
>> [x86 XP trunk (Joseph Armbruster)]
>> This box didn't survive the recent build changes, but I can't figure out 
>> why, none of the other Windows boxes encounter this error:
>> The following error has occurred during XML parsing:
>> File: 
>> C:\python\buildarea\trunk.armbruster-windows\build\PCbuild\_bsddb.vcproj
>> Line: 179
>> Column: 1
>> Error Message:
>> Illegal qualified name character.
>> The file 
>> 'C:\python\buildarea\trunk.armbruster-windows\build\PCbuild\_bsddb.vcproj' 
>> has failed to load.
>>
>> Can someone check a clean trunk build on a Windows system that *only* has 
>> Visual C++ Express 2008?  The latest build system updates don't rely on any 
>> features of Visual Studio Professional, but the tools use a lot of common 
>> files, and perhaps a Service Pack needs to be applied or something.
> 
> I just built the trunk on a Windows XP x86 box that only has Visual C++
> Express 2008 installed.  I got a bunch of errors with sqlite, tcl,
> db-4.4.20, and ssl, but the interpreter built and appears to run ok.
> 
> But since I don't have bsddb installed, I don't think I'm executing the
> portion of the build process that you find failing.
> 
> I don't have time to install bsddb tonight, but I can do that in about
> 24 hours if you still need me to.
> 
> Eric.
> 

___
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-archive.com

Re: [Python-Dev] trunk buildbot status

[Trent Nelson]

Thanks Eric, very useful to know.  I guess it's just that particular build 
slave...


From: Eric Smith [EMAIL PROTECTED]
Sent: 20 March 2008 02:55
To: Trent Nelson
Cc: python-dev@python.org
Subject: Re: [Python-Dev] trunk buildbot status

Trent Nelson wrote:
> I'd recommend cd'ing to your trunk root directory and running 
> Tool\buildbot\build.bat from there -- it'll automatically check out all the 
> dependencies and build via command line with vcbuild (building via Visual 
> Studio usually always Does The Right Thing, command line builds often take a 
> bit more coercing).

Okay, that's extremely helpful.  With that (and installing nasmw.exe), a
trunk checkout builds correctly and passes all tests (although skipping
test_tcl) on my box.  As I said, it's XP x86 with 2008 Express Edition only.

Let me know if I can provide any other information.  Unfortunately I
don't have access to this box during the work day (EDT), and I'm leaving
for vacation tomorrow (Friday).  But I'll help as best I can.

Eric.

>
> 
> From: Eric Smith [EMAIL PROTECTED]
> Sent: 19 March 2008 20:49
> To: Trent Nelson
> Cc: python-dev@python.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL 
> PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [Python-Dev] trunk buildbot status
>
> Trent Nelson wrote:
>> Quick update on the status of the trunk buildbots:
>>
>> [x86 XP trunk (Joseph Armbruster)]
>> This box didn't survive the recent build changes, but I can't figure out 
>> why, none of the other Windows boxes encounter this error:
>> The following error has occurred during XML parsing:
>> File: 
>> C:\python\buildarea\trunk.armbruster-windows\build\PCbuild\_bsddb.vcproj
>> Line: 179
>> Column: 1
>> Error Message:
>> Illegal qualified name character.
>> The file 
>> 'C:\python\buildarea\trunk.armbruster-windows\build\PCbuild\_bsddb.vcproj' 
>> has failed to load.
>>
>> Can someone check a clean trunk build on a Windows system that *only* has 
>> Visual C++ Express 2008?  The latest build system updates don't rely on any 
>> features of Visual Studio Professional, but the tools use a lot of common 
>> files, and perhaps a Service Pack needs to be applied or something.
>
> I just built the trunk on a Windows XP x86 box that only has Visual C++
> Express 2008 installed.  I got a bunch of errors with sqlite, tcl,
> db-4.4.20, and ssl, but the interpreter built and appears to run ok.
>
> But since I don't have bsddb installed, I don't think I'm executing the
> portion of the build process that you find failing.
>
> I don't have time to install bsddb tonight, but I can do that in about
> 24 hours if you still need me to.
>
> Eric.
>
___
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-archive.com

Re: [Python-Dev] First green Windows x64 buildbots!

[Thomas Heller]

Trent Nelson schrieb:
> We've just experienced our first 2.6 green x64 Windows builds on the
> build slaves!  Well, almost green.  Thomas's 'amd64 XP trunk' ran out
> of disk:
> 
> 304 tests OK. 1 test failed: test_largefile 
> ==
>  ERROR: test_seek (test.test_largefile.TestCase) 
> --
>  Traceback (most recent call last): File
> "C:\buildbot\trunk.heller-windows-amd64\build\lib\test\test_largefile.py",
> line 42, in test_seek f.flush() IOError: [Errno 28] No space left on
> device
> 
> Sorry about that Thomas ;-)

Trent - that's great.  I'll try to free some diskspace.

Thomas

___
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-archive.com

Re: [Python-Dev] trunk buildbot status

[Thomas Heller]

>>  Neal/Martin, I'd like to promote the following slaves to the stable list:
>>  [g4 osx.4]
>>  [x86 W2k8]
>>  [AMD64 W2k8]
>>  [ppc Debian unstable]
>>  [sparc Ubuntu]
>>  [sparc Debian]
>>  [PPC64 Debian]
>>  [S-390 Debian]
>>  [x86 XP-3]
>>  [amd64 XP]
>>  [x86 FreeBSD]
>>  [x86 FreeBSD 3]
>>
>>  The trunk builds of these slaves have been the most reliable since I've 
>> been tracking.
> 
> Most of these have already been promoted to stable.  I just didn't
> restart the buildbot master since making the change.  It requires a
> restart, not just a reconfig.  I was waiting for a quiet time when the
> bots weren't busy, but that hasn't happened yet. :-)  I can make more
> changes and restart when I get home.

Hm, what is this 'stable list' anyway?

BTW: Although the x86 XP-3 and x86 W2k8 bots are green, there's still a problem:
test_tcl
test_tcl skipped -- DLL load failed: The specified module could not be found.

AFAIK, this is because tcl86g.dll and tk86g.dll fail to load because they 
cannot find
MSVCR90D.DLL; do these dlls need a manifest?

Thomas

___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Paul Moore]

On 20/03/2008, zooko <[EMAIL PROTECTED]> wrote:
> On Mar 19, 2008, at 3:23 PM, Guido van Rossum wrote:
>
>  > If other people want to chime in please do so; if this is just a
>  > dialog between Phillip and me I might incorrectly assume
>  > that nobody besides Phillip really cares.
>
> I really care.  I've used setuptools, easy_install, eggs, and
>  pkg_resources extensively for the past year or so (and contributed a
>  few small patches).  There have been plenty of problems, but I find
>  them to be overall useful tools.

I'll chime in here, too. I really want to like
setuptools/easy_install, but I don't. I'll try to be specific in my
reasons, in the hope that they can be addressed. I know some of these
are "known about", but one of my meta-dislikes of setuptools is that
known issues never seem to get addressed (I know, patches accepted,
but I haven't got the time either...)

1. No integration with the system packager (Windows, in my case). If I
do easy_install nose, then nose does not show up in add/remove
programs. That significantly affects the way I manage my PC.

2. No uninstaller. After easy_install nose, how do I get rid of it
later? Searching for files to delete (even if there are only a few
obviously named ones) is not good enough.

3. The pkg_resources documentation (in particular, that's the one I've
tried to follow) is extremely hard to read. Partly this is just style,
but it's partly because it is couched in very unfamiliar terms
(distributions, working sets, interfaces, providers, etc). It's also
*huge*. A tutorial style overview, supported by API detail, would be
far better.

4. Hard to use with limited connectivity. At work, I *only* have
access to the internet via Internet Explorer (MS based proxy). There
are workarounds, but ultimately "download an installer, then run it"
is a far simpler approach for me.

5. Auto-discovery doesn't always work. I'm sorry, I really can't
recall the example at the moment, but sometimes easy_install says it
can't find a package I *know* is available.

6. Splitting the community. Windows users rely heavily on binary
installers (at least, I do). We're starting to get a situation where
some projects provide .egg files, and some provide traditional
(bdist_wininst/bdist_msi) installers. This is bad. One way to do it,
and all that :-)

But if these problems are solved, then I have no problem with seeing
the features of setuptools added to the standard library - resource
APIs, plugin/entry point APIs, ways to create executable scripts, and
such things *should* be standardised. Dependency resolution and
automatic installation isn't something I like (probably because as a
Windows user I've never used such a system, so I mistrust it) but if
it works *with* the system and not against it, I don't mind.

I hope this helps,
Paul.
___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[glyph]

On 09:33 am, [EMAIL PROTECTED] wrote:
>I'll chime in here, too. I really want to like
>setuptools/easy_install, but I don't. I'll try to be specific in my
>reasons, in the hope that they can be addressed. I know some of these
>are "known about", but one of my meta-dislikes of setuptools is that
>known issues never seem to get addressed (I know, patches accepted,
>but I haven't got the time either...)

I agree with almost everything that Paul says, and he put it quite well, 
so I'll spare the "me too", but I do have some additional gripes to add.

setuptools (or, for that matter, distutils) has no business installing 
stuff in the system directory on a Linux box with a package manager. 
The *major* benefit I can see to a tool like easy_install is providing a 
feature that system packagers do not: allowing developers to quickly 
pull down all their dependencies into a *user directory* without 
worrying about system administration.  However, not only does setuptools 
not do this on its own, it actively fights me when I try to do it.

Admittedly, my user directory is a little messed up.  Combinator, the 
Divmod path management / developer deployment tool, does some 
inadvisable things to attempt to trick distutils into doing local 
installation.  However, setuptools does have some pretty clear bugs in 
this area; for example, it hard-codes a copy of a list that's present in 
site.py to try to figure out where .pth files will be honored, rather 
than looking at what's actually on sys.path.  Every time I've tried to 
install a package for development using setuptools - and I am speaking 
across a wide range of versions here, so this isn't a specific bug 
report - it's either emitted a completely inscrutable traceback or 
printed an error message telling me that it couldn't or wouldn't install 
to the provided location.
>But if these problems are solved, then I have no problem with seeing
>the features of setuptools added to the standard library - resource
>APIs, plugin/entry point APIs, ways to create executable scripts, and
>such things *should* be standardised. Dependency resolution and
>automatic installation isn't something I like (probably because as a
>Windows user I've never used such a system, so I mistrust it) but if
>it works *with* the system and not against it, I don't mind.

This is more of a vague impression than a specific technical criticism, 
but it really seems like the implementation of these features face a lot 
of unnecessary coupling in setuptools.  Twisted (Hey, did you guys know 
I work on Twisted?  It seems I hardly ever mention it!), for example, 
implements resource APIs (twisted.python.modules), plugins 
(twisted.plugin, which is a bit like some of the uses of entrypoints), 
and the zip-file agnosticism of both (twisted.python.zipstream) without 
needing any packaging metadata or ini files.  It just introspects the 
Python path and adds a little frosting to importers.

I could be wrong about setuptools' actual design; this could be a 
documentation or UI issue, because I haven't read the code.  But when 
interacting with it as a user and perusing its API, it definitely seems 
as though things are woven too tightly together, and the whole thing is 
very centered around the concept of a "build", i.e. running some kind of 
compilation or deployment step with a setup.py.  One of my favorite 
things about python is that stuff just runs without needing that 
normally.  I know that "setup.py develop" is supposed to avoid that - 
but even that itself is a deployment step which generates some metadata. 
With the setuptools-free libraries I use, it's just check out, then run; 
no other intermediary step.  I'm spoiled, of course, having apt to do 
the package-management work for me on the majority of my dependencies, 
and combinator mostly handling the rest.

easy_install also definitely has problems with security.  It 
automatically downloads links from plain-HTTP connections, some of them, 
I believe, from publicly editable wiki pages, and installs them with no 
verification of signatures (as root!  because how else are you going to 
get them to the only supported installation directory!).  I believe that 
this is possibly the easiest issue to fix though, and I hope that my 
information here is already out of date.  I realize that people are 
already doing this (insecure installation) with their web browsers, but 
there are tons of UI cues in a web browser looking at a link on a wiki 
page which you don't get from an automated command-line tool.

As others have said, I wanted to like setuptools.  I wanted to believe 
we could be saved from the unfortunate issues with distutils.  But the 
extremely high degree of frustration I've encountered every time I've 
tried to use it, its general inscrutability, its awful UI ("python -c 
"import setuptools; execfile('setup.py')" develop", seriously?  you 
couldn't write a command-line tool to make that look like 'setuptool 
develop' or something?) and n

Re: [Python-Dev] Consistent platform name for 64bit windows (was: distutils.util.get_platform() for Windows)

[M.-A. Lemburg]

On 2008-03-18 18:05, [EMAIL PROTECTED] wrote:
> I'm reviving a very old thread based on discussions with Martin at pycon.
> 
>> Sent: Monday, 23 July 2007 5:12 PM
>> Subject: Re: [Distutils] distutils.util.get_platform() for Windows
> 
> Rather than forcing everyone to read the context, allow me to summarize:
> On 64bit Windows versions, we need a "string" that identifies the
> platform, and this string should ideally be used consistently.  This
> original thread related to the files created by distutils (eg,
> pywin32-210.win???64??-py2.6.exe) but it seems obvious that we should be
> consistent wherever Python wants to display the platform (eg, in the
> startup banner, in platform.py, etc).
> 
> In the old thread, there was a semi-consensus that 'x86_64' be used by
> distutils (and indeed, Lib/distutils/util.py in get_platform() has been
> changed, by me, to use this string), but the Python 'banner', for example,
> reports AMD64.  Platform.py doesn't report much at all in this area, at
> least when pywin32 isn't installed, but it arguably should.
> 
> Both Martin and I prefer AMD64 as the string, for various reasons. 
> Firstly, it is less ugly than 'x86_64', and doesn't include an '_'/'-'
> which might tend to confuse parsing by humans or computers.  Martin also
> made the point that AMD invented the architecture and AMD64 is their
> preferred name, so we should respect that.
> 
> So, at the risk of painting a bike-shed, I'd like to propose that we adopt
> 'AMD64' in distutils (needs a change), platform.py (needs a change to use
> sys.getwindowsversion() in preference to pywin32, if possible, anyway),
> and the Python banner (which already uses AMD64).
> 
> Any objections?  Any strong feelings that using 'AMD' will confuse people
> with Intel processors?  Strong feelings about the parsability of the name
> (PJE? )?  Strong feelings about the color ?

Not really an object, but Microsoft itself uses the term "x64" for
the 64-bit variants of their OS, e.g.

http://www.microsoft.com/windowsxp/64bit/default.mspx

Since the platform name is targeting Windows, I think we should
avoid confusing Windows users more than Intel users ;-)

About the platform.py changes: if someone could provide the return
values of sys.getwindowsversion() for 64bit versions of Windows
XP and Vista, I could add support for it (don't have a 64bit version
of Windows available to check myself).

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 20 2008)
 >>> Python/Zope Consulting and Support ...http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
___
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-archive.com

Re: [Python-Dev] The Breaking of distutils and PyPI for Python 3000?

[Martin v. Löwis]

> "... encouraged in __3.x guidelines__ to ...": I presume although I've not 
> found them yet that there is some kind of document for developers titled 
> something like, "how to migrate your Python code from 2.x to 3.x".  That 
> document would be a logical place for advice and consideration of the 
> tradeoffs of jumping to 3.x, maintaining two synced versions using 2to3 or 
> 3to2, and the risks of keeping two independent releases.  Identifying best 
> practices would help them make good choices for the community.

I don't think any of the core committers is qualified to write such
a document. Instead, it would have to be written by people who
*actually* ported a project from 2 to 3 in some form.

That is not to say that such a document couldn't be part of the 3k
release, or shouldn't be reviewed by core committers.

[Also, it might turn out that some of the core committers writes such
a document, with the theoretical background of what *could* work
for projects. That would be a lot like all those books giving advise
written by people who never followed their own advise because they
never had a chance to].

> So we don't have an actual success story of a dual-version distribution, even 
> as a prototype, using 2to3 within a distutils package?  I would not encourage 
> a practice without at least one such example.

We don't have any success story for Python 3, period. Nobody has ever
attempted to run a significant code base in Python 3, other than the
test suite, AFAIK.

>> It always worked fine for me, so I see no reason to fix it in the
>> first place.
> 
> Pardon my lack of knowledge of your background; when you say it always worked 
> fine for you, are you referring to personal experiences using it to _install_ 
> software or to experiences as a packager in actually distributing complex 
> collections of modules on different platforms?

I've been maintaining a larger project (PyXML) for several years, and
have written/maintained a few smaller projects (iconv, partial,
python-fam), which all used distutils. I have also extended distutils
in the core, with the upload and bdist_msi commands. And then
there is the experience with installing distutils-based packages,
which is usually pleasant (although I prefer to use the Debian
package where available)

Regards,
Martin
___
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-archive.com

Re: [Python-Dev] Pretty-printing 2to3 Nodes

[Martin v. Löwis]

> OR just names:
> Node(import_name, [Leaf(1, 'import'), Node(dotted_as_name, [Node 
> (dotted_name, [Leaf(1, 'foo'), Leaf(23, '.'), Leaf(1, 'bar')]), Leaf 
> (1, 'as'), Leaf(1, 'bang')])])

This is the one I prefer.

Regards,
Martin

___
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-archive.com

Re: [Python-Dev] PyCon: please review miy pending patches

[Andrew MacIntyre]

Christian Heimes wrote:

> Memory management of ints, floats and longs
> http://bugs.python.org/issue2039
> http://bugs.python.org/issue2013

wrt 2039 - I would like to see the free list compaction called from 
gc.collect() rather than a function in sys... something you suggested.

As I noted in the comments to 2039, in the presence of pymalloc there is
almost no value to floats having a freelist as far as I can test - other 
than in microbenchmarks.

I see from a comment in 2013 that you were testing that patch with a 
debug build, which skews the timings.  If your performance evaluation of 
2039 was also done with a debug build, I suggest you try it with a 
non-debug build (which is what I used for all my testing).

-- 
-
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: [EMAIL PROTECTED]  (pref) | Snail: PO Box 370
[EMAIL PROTECTED] (alt) |Belconnen ACT 2616
Web:http://www.andymac.org/   |Australia
___
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-archive.com

Re: [Python-Dev] Consistent platform name for 64bit windows (was: distutils.util.get_platform() for Windows)

[Thomas Heller]

M.-A. Lemburg schrieb:
> About the platform.py changes: if someone could provide the return
> values of sys.getwindowsversion() for 64bit versions of Windows
> XP and Vista, I could add support for it (don't have a 64bit version
> of Windows available to check myself).

This is the output of a 32-bit Python running on "Windows XP Professional
x64 Edition, Version 2003, Service Pack 2":

C:\Python24>ver

Microsoft Windows [Version 5.2.3790]

C:\Python24>python
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getwindowsversion()
(5, 2, 3790, 2, 'Service Pack 2')
>>>



Thomas

___
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-archive.com

Re: [Python-Dev] trunk buildbot status

[skip]

Neal> Unfortunately, I don't have ssh access from my hotel room.  This
Neal> means I won't be able to help much until I get home.

There's always the hideously priced access at O'Hare. ;-)

Skip
___
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-archive.com

Re: [Python-Dev] Consistent platform name for 64bit windows (was: distutils.util.get_platform() for Windows)

[M.-A. Lemburg]

On 2008-03-20 13:42, Thomas Heller wrote:
> M.-A. Lemburg schrieb:
>> About the platform.py changes: if someone could provide the return
>> values of sys.getwindowsversion() for 64bit versions of Windows
>> XP and Vista, I could add support for it (don't have a 64bit version
>> of Windows available to check myself).
> 
> This is the output of a 32-bit Python running on "Windows XP Professional
> x64 Edition, Version 2003, Service Pack 2":
> 
> C:\Python24>ver
> 
> Microsoft Windows [Version 5.2.3790]
> 
> C:\Python24>python
> Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
 import sys
 sys.getwindowsversion()
> (5, 2, 3790, 2, 'Service Pack 2')

Thank you !

Anyone with a 64bit Vista ?

Or even better: a page documenting what to expect from the system call
behind the sys.getwindowsversion() API ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 20 2008)
 >>> Python/Zope Consulting and Support ...http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Moore wrote:

> I'll chime in here, too. I really want to like
> setuptools/easy_install, but I don't. I'll try to be specific in my
> reasons, in the hope that they can be addressed. I know some of these
> are "known about", but one of my meta-dislikes of setuptools is that
> known issues never seem to get addressed (I know, patches accepted,
> but I haven't got the time either...)

Thanks for feedback from the Windows world, from whence I have been
blissfully exiled now for years.

> 1. No integration with the system packager (Windows, in my case). If I
> do easy_install nose, then nose does not show up in add/remove
> programs. That significantly affects the way I manage my PC.

Point taken. Of course, it isn't really a "program" at that point:  it
is an installed "add-on" to Python.  However, if Windows users expect
such add-ons to show up in the "system" list, that is good to know.

I'll note that I use easy_install *only* to work in *non-system*
locations:  if I want to install Python packages to /usr/lib/python2.x/,
I use the standard system installer, e.g. 'apt-get install
python-frobnatz'.  But I routinely create non-system Python environments
for development, using either alternate Pythons or virtualenv:  in those
environments, it works very well for me.

> 2. No uninstaller. After easy_install nose, how do I get rid of it
> later? Searching for files to delete (even if there are only a few
> obviously named ones) is not good enough.

People ask for this on Unix platforms as well, often adding a request
that pacakges installed only as dependencies of the
package-being-removed go away as well.  If you install everything in a
way that works with system package manager, of course, you don't need
this. ;)

Deleting the 'lib/python2.x/site-packages/foo-X.Y.X.egg' directory is
all that is actually required to uninstall an egg that was previouly
added via easy_install.  Cleaning out the equivalent entry in
'easy_install.pth' in that directory is not strictly required.

I wonder if a GUI for managing the add-ons would fit the bill, as an
alternative to packaging them as though they were standalone programs?

> 3. The pkg_resources documentation (in particular, that's the one I've
> tried to follow) is extremely hard to read. Partly this is just style,
> but it's partly because it is couched in very unfamiliar terms
> (distributions, working sets, interfaces, providers, etc). It's also
> *huge*. A tutorial style overview, supported by API detail, would be
> far better.

Many of those terms are distutils jargon, actually.  I think Jeff Rush'
recent work looks like a good start here.

> 4. Hard to use with limited connectivity. At work, I *only* have
> access to the internet via Internet Explorer (MS based proxy). There
> are workarounds, but ultimately "download an installer, then run it"
> is a far simpler approach for me.

I don't know how to make this requirement compatible with using shared
dependencies, except to make it easier for folks to download *all* the
requirements, and later install from the local "distribution cache" (a
directory full of .zip / .egg / .tgs files).  It does turn out to be
quite easy to build a PyPI-style "simple" index for such a cache.  Your
use case would then require:

 1. Run some command to fetch the desired package and the transitive
closure of its dependencies into a working directory (the cache).

 2. Run another command to build an index for that directory.

 3. Run 'easy_install', pointing to the local index.

> 5. Auto-discovery doesn't always work. I'm sorry, I really can't
> recall the example at the moment, but sometimes easy_install says it
> can't find a package I *know* is available.

Usually this indicates that there are incompatible dependencies between
packages already installed and those on the index.  E.g., if I already
have package foo installed, but its version is not compatible with the
requirements for package bar, then I can't install bar, even though the
distribution is "available."

Because PyPI is not a centrally-managed index of packages, such
conflicts are pretty much inevitable over time for those who don't
subset it in some form (what we've been calling the "known good set"
strategy in Zope-land).

> 6. Splitting the community. Windows users rely heavily on binary
> installers (at least, I do). We're starting to get a situation where
> some projects provide .egg files, and some provide traditional
> (bdist_wininst/bdist_msi) installers. This is bad. One way to do it,
> and all that :-)

If it weren't for the "Add / Remove Programs" requirement you mentioned
above, we would be better off if authors of pure Python packages
uploaded only 'sdist' distributions, which can be cleanly converted to
platform-local eggs at install time, even on Windows.  Packages which
contain C extensions typically must upload the 'bdist_win' version for
the benefit of the vast majority of Windows users who can't 

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Bob Kline]

Tres Seaver wrote:
> Point taken. Of course, it isn't really a "program" at that point:  it
> is an installed "add-on" to Python.  However, if Windows users expect
> such add-ons to show up in the "system" list, that is good to know.
>   

Are things really that different in the non-Windows worlds?  If I want 
python-nose, I run "sudo apt-get install python-nose" (and that means I 
can always remove it with "sudo apt-get remove ...").  Seems more 
similar than different (ignoring the silliness of Microsoft's insistence 
on "the GUI is the OOWTDI" even for such administrative tasks as 
installing system-wide software).

-- 
Bob Kline
http://www.rksystems.com
mailto:[EMAIL PROTECTED]

___
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-archive.com

Re: [Python-Dev] Improved thread switching

[Jesse Noller]

FYI: I shot an email to stdlib-sig about the fact I am proposing the
inclusion of the pyProcessing module into the stdlib. Comments and
thoughts regarding that would be welcome. I've got a rough outline of
the PEP, but I need to spend more time with the code examples.

-jesse

On Wed, Mar 19, 2008 at 9:52 PM, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Hmmm, sorry if I'm missing something obvious, but, if the occasional
>  background computations are sufficiently heavy -- why not fork, do
>  said computations in the child thread, and return the results via any
>  of the various available IPC approaches?  I've recently (at Pycon,
>  mostly) been playing devil's advocate (i.e., being PRO-threads, for
>  once) on the subject of utilizing multiple cores effectively -- but
>  the classic approach (using multiple _processes_ instead) actually
>  works quite well in many cases, and this application server would
>  appear to be one.  (the pyProcessing package appears to offer an easy
>  way to migrate threaded code to multiple-processes approaches,
>  although I've only played around with it, not [yet] used it for
>  production code).
>
>
>  Alex
>
>
>
>  On Wed, Mar 19, 2008 at 10:49 AM, Adam Olsen <[EMAIL PROTECTED]> wrote:
>  > On Wed, Mar 19, 2008 at 11:25 AM, Stefan Ring <[EMAIL PROTECTED]> wrote:
>  >  > Adam Olsen  gmail.com> writes:
>  >  >
>  >  >
>  >  > > So you want responsiveness when idle but throughput when busy?
>  >  >
>  >  >  Exactly ;)
>  >  >
>  >  >
>  >  >  > Are those calculations primarily python code, or does a C library do
>  >  >  > the grunt work?  If it's a C library you shouldn't be affected by
>  >  >  > safethread's increased overhead.
>  >  >  >
>  >  >
>  >  >  It's Python code all the way. Frankly, it's a huge mess, but it would 
> be very
>  >  >  very hard to come up with a scalable solution that would allow to 
> optimize
>  >  >  certain hotspots and redo them in C or C++. There isn't even anything 
> left to
>  >  >  optimize in particular because all those low hanging fruit have 
> already been
>  >  >  taken care of. So it's just ~30kloc Python code over which the total 
> time spent
>  >  >  is quite uniformly distributed :(.
>  >
>  >  I see.  Well, at this point I think the most you can do is file a bug
>  >  so the problem doesn't get forgotten.  If nothing else, if my
>  >  safethread stuff goes in it'll very likely include a --with-gil
>  >  option, so I may put together a FIFO scheduler.
>  >
>  >
>  >  --
>  >  Adam Olsen, aka Rhamphoryncus
>  >
>  >
>  > ___
>  >  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/aleaxit%40gmail.com
>
>
> >
>  ___
>  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/jnoller%40gmail.com
>
___
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-archive.com

Re: [Python-Dev] platform management

[Bill Janssen]

Looking at http://docs.python.org/lib/module-os.html, I find the following:

  name
  
The name of the operating system dependent module imported. The
following names have currently been registered: 'posix', 'nt', 'mac',
'os2', 'ce', 'java', 'riscos'.

This implies that there's a registry somewhere?

Bill

> Great idea! Sounds like a PEP (informational, probably) would be good idea.
> 
> On Tue, Mar 18, 2008 at 4:59 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > I don't think this is bike-shedding.
> >
> >  The debate about "AMD64" vs. "amd64" vs. "x86_64" reminded me that
> >  I've been bit more and more frequently by bits of platform-specific
> >  knowledge scattered around the standard library.  The latest is the
> >  code in distutils.unixccompiler that tries to figure out what flags to
> >  send to the linker in order to add a dynamic library path lookup to a
> >  shared library.
> >
> >  There are lots of different ways of figuring out which platform is
> >  being used, and they're all over the place.  The code in
> >  distutils.unixccompiler uses "sys.platform[:6]", and looks for
> >  "darwin"; the code in urllib.py uses "os.name", and expects it to be
> >  "mac", but later looks for "sys.platform == 'darwin'; posixfile
> >  believes that platforms come with version numbers ("linux2", "aix4");
> >  pydoc and tarfile have tests for "sys.platform == 'mac'".  tempfile
> >  looks at os.sys.platform *and* os.name.
> >
> >  Could well be that all of these are correct (I believe that "mac", for
> >  instance, refers to the generations of the Mac OS before OS X).  But
> >  it means that when someone tries to update "Python" to a new major
> >  version release for, say, OS X, it's really easy to miss things.  And
> >  the fact that the platform version is sometimes included and sometimes
> >  not is also problematic; darwin9 is different from darwin8 in some
> >  important aspects.
> >
> >  It would be nice to
> >
> >   (a) come up with a list of standard platform symbols,
> >   (b) put those symbols somewhere in the documentation,
> >   (c) have one way of discovering them, via sys or os or platform or
> >   whichever module,
> >   (d) add a standard way of discovering the platform version, and
> >   (e) stamp out all the other ways that have crept in over the years.
> >
> >  Bill
> >  ___
> >  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/guido%40python.org
> >
> 
> 
> 
> -- 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Tim Golden]

Bob Kline wrote:
> Are things really that different in the non-Windows worlds?  If I want 
> python-nose, I run "sudo apt-get install python-nose" (and that means I 
> can always remove it with "sudo apt-get remove ...").  Seems more 
> similar than different (ignoring the silliness of Microsoft's insistence 
> on "the GUI is the OOWTDI" even for such administrative tasks as 
> installing system-wide software).

I was going to -- pointedly -- drop in here the help output
for msiexec, which is the commandline version of the MSI
installation graphical stuff. Only... when I did msiexec /?,
the result was that a Window popped up with the information
in it. (Sort of agrees with your point a bit!)

Still, here's the info (cut-and-pasted from that window):

-

Windows ® Installer. V 3.01.4000.1823

msiexec /Option  [Optional Parameter]

Install Options
 
Installs or configures a product
/a 
Administrative install - Installs a product on the network
/j  [/t ] [/g ]
Advertises a product - m to all users, u to current user
 
Uninstalls the product


[... snip lots of other options ...]

TJG
___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Martin v. Löwis]

Guido van Rossum schrieb:
> I was using the human interface at python.org/pypi. There are two
> prominent links at the top of the page: "Browse the tree of packages"
> and "Submit package information" followed by the 30 most recently
> changed packages.

Ah, ok. In PyPI parlance, these are "classifiers" (Trove classifiers,
although the word "trove" means nothing to me), not keywords. They
are different from keywords in the sense that they form a hierarchy.

I personally consider trove classifiers over-valued, but apparently,
some people really love them (probably the ones who are more organized
than I am). Developers continuously request addition of new classifiers;
I don't have any statistics whether users actually use them to locate
stuff.

> What I was looking for was the page for a specific
> package. The "Browse the tree of packages" link was no help. Finally I
> realized that in the side bar, in a small unobtrusive font, is a link
> to "List packages" which links to a list of *all* packages, in
> alphabetical order. I found my package there. I think repeating that
> link right below "browse the tree" would have been sufficient. 

I can't change that right now, but created

http://sourceforge.net/tracker/index.php?func=detail&aid=1921108&group_id=66150&atid=513503

> But it
> would have been cool if there had been a search box (also in the start
> page) where I could type (part of) the name of the package and it
> would have given me the nearest matches.

Did you try the search box in the top-right, and did did not work?

What search term did you enter, and what package did you expect to get?

Regards,
Martin

___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Phillip J. Eby]

At 12:58 AM 3/20/2008 -0400, Tres Seaver wrote:
>A lot of setuptools warts are driven by related design problems in the
>distutils, such as the choice to use imperative / procedural code for
>everything:  a declarative approach, with hooks for cases which actually
>need them (likely 5% of existing packages) would have made writing tools
>on top of the framework much simpler.  It is ironic that Python is *too
>powerful* a tool for the tasks normally done by distutils / setuptools:
>  a more restricted, and thererfore introspectable, configuration-driven
>approoach seems much cleaner.

+1

___
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-archive.com

[Python-Dev] [Distutils-SIG] PYTHONPATH installation (was Re: PEP 365 (Adding the pkg_resources module))

[Phillip J. Eby]

At 10:18 PM 3/19/2008 -0600, zooko wrote:
>The fact that easy_install creates a site.py that changes the
>semantics of PYTHONPATH is probably the most widely and deservedly
>hated example of this kind of thing [2].

Yep, this was an unfortunate side effect of eggs growing outside 
their original ecological niche.  Without the 'site' hack, it was 
impossible to install eggs to user directories and avoid installation 
conflicts.

Specifically, if someone installed a package to PYTHONPATH with the 
distutils, and then installed a later version using setuptools, the 
setuptools-installed version would always end up on sys.path *after* 
the distutils-installed version.  Detecting this condition and 
handling it properly was a major problem for users of easy_install, 
who wanted it to "just work".

Standardization of a PEP 262-style installation database is still 
needed to address these problems, not to mention 
uninstallation.  Maybe now with some package manager folks paying 
some attention here, we can do something about that.


>[2] http://www.rittau.org/blog/20070726-02
>And no, PJE's suggested "trivial fix" does not satisfy the
>objectors, as it can't support the use case of "cd somepkg ; python 
>./ setup.py install ; cd .. ; python -c 'import somepkg'".

Well, it replaces the hack being complained about, with the problem 
that the hack was introduced to fix.  :)

Again, to properly fix this, we need a metadata standard for who owns 
what packages -- and it should probably include information about the 
*tool* that did the installation, so that system packagers can either 
tell Python-level tools to keep their hands off, or tell Python how 
to run the tool in question.

___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Phillip J. Eby]

At 09:33 AM 3/20/2008 +, Paul Moore wrote:
>1. No integration with the system packager (Windows, in my case). If I
>do easy_install nose, then nose does not show up in add/remove
>programs. That significantly affects the way I manage my PC.

The long-term fix here is probably to have a platform-specific 
installer capable of either turning eggs into .msi or .exe 
installers, or of doing the add/remove programs integration 
directly.  (Someone, of course, will have to step up to create such a tool.)


>5. Auto-discovery doesn't always work. I'm sorry, I really can't
>recall the example at the moment, but sometimes easy_install says it
>can't find a package I *know* is available.

Sometimes it does that to me, too.  But then I look at the project's 
page in PyPI, and they don't have a link to a download 
page.  Usually, they've got a link to a page on their site with 
instructions about downloading, but that doesn't directly link to any 
tarballs or anything.  So I grab the link of the real download page 
and paste it into a -f option to easy_install, so it knows where to 
find the link from.


___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Phillip J. Eby]

At 09:44 AM 3/20/2008 -0400, Tres Seaver wrote:
>I don't know how to make this requirement compatible with using shared
>dependencies, except to make it easier for folks to download *all* the
>requirements, and later install from the local "distribution cache" (a
>directory full of .zip / .egg / .tgs files).  It does turn out to be
>quite easy to build a PyPI-style "simple" index for such a cache.  Your
>use case would then require:
>
>  1. Run some command to fetch the desired package and the transitive
> closure of its dependencies into a working directory (the cache).
>
>  2. Run another command to build an index for that directory.
>
>  3. Run 'easy_install', pointing to the local index.

Actually, if someone were to develop a patch for PyPI to do this, we 
could perhaps have a "display download dependencies" link for eggs 
shown on PyPI.  That way, someone who wants to do a manual download 
could get a page with links for all the required eggs, and manually 
download them.

(Of course, the other alternative would be for someone to provide an 
IE-controlling extension to urllib2 so that easy_install wouldn't be 
proxy-bound on such machines.) 

___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Jeroen Ruigrok van der Werven]

-On [20080320 15:29], "Martin v. Löwis" ([EMAIL PROTECTED]) wrote:
>(Trove classifiers, >although the word "trove" means nothing to me)

Isn't that something lifted from SourceForge?

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
The Eyes of Truth are always watching you...
___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Jeroen Ruigrok van der Werven]

-On [20080320 05:58], Tres Seaver ([EMAIL PROTECTED]) wrote:
>I think that, warts an all, setuptools is a *huge* improvement over bare
>distutils for nearly every use case I know about.

Agreed.

I see setuptools (along with PyPI - hopefully much better in near future
though) as the Python equivalent to CPAN and RubyGems.

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
Sadness is the inner beauty of the untouched tear...
___
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-archive.com

Re: [Python-Dev] Improved thread switching

[Andrew McNabb]

On Thu, Mar 20, 2008 at 09:58:46AM -0400, Jesse Noller wrote:
> FYI: I shot an email to stdlib-sig about the fact I am proposing the
> inclusion of the pyProcessing module into the stdlib. Comments and
> thoughts regarding that would be welcome. I've got a rough outline of
> the PEP, but I need to spend more time with the code examples.

Since we officially encourage people to spawn processes instead of
threads, I think that this would be a great idea.  The processing module
has a similar API to threading.  It's easy to use, works well, and most
importantly, gives us some place to point people to when they complain
about the GIL.


-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868


signature.asc
Description: Digital signature
___
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-archive.com

Re: [Python-Dev] Checking for the -3 flag from Python code

[Steven Bethard]

On Wed, Mar 19, 2008 at 5:51 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> This flag is exposed to python code as sys.flags.py3k_warning
>
>  So the hack added to some of the test code that I saw go by on
>  python-checkins isn't needed :)

Excellent.  I asked around at the sprints and everyone thought it was
unexposed.  If no one else has already done it, I'll remove the hacks
from test_py3kwarn and the regrtest skipping mechanism.

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
 --- Bucky Katt, Get Fuzzy
___
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-archive.com

Re: [Python-Dev] Trove classifiers

[Oleg Broytmann]

On Thu, Mar 20, 2008 at 04:43:55PM +0100, Jeroen Ruigrok van der Werven wrote:
> -On [20080320 15:29], "Martin v. L??wis" ([EMAIL PROTECTED]) wrote:
> >(Trove classifiers, >although the word "trove" means nothing to me)
> 
> Isn't that something lifted from SourceForge?

   Yes, exactly. Eric Raymond claims to be the inventor, but there are
different voices against him:
http://damagestudios.net/blog/2005/08/15/sourceforge-founders

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
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-archive.com

[Python-Dev] The "autoinstall" package just uploaded to PyPI

[Phillip J. Eby]

I just wanted to throw in a quick note that this package:

http://pypi.python.org/pypi/autoinstall

which was just uploaded by Daniel Krech, is a lot closer in spirit to 
what I was trying to accomplish with PEP 365 than Guido's bootstrap 
proposal.  Perhaps there's room for both in the stdlib?  (And note 
that even though the examples use eggs, it does not do anything 
egg-specific; any zipfile importable by Python works with autoinstall.)

There are a number of changes I would suggest making to autoinstall, 
like making it possible to access information about files in the 
cache, supporting non-toplevel modules, programmatic and 
environment-level control of the cache directory, that sort of 
thing.  Heck, it'd be nice (although not essential) for it to support 
finding the right URL from PyPI.

I also suspect that users might want to have some way to disable it 
or restrict it to certain hosts, etc., perhaps through a 
configuration file.  It should probably also default the cache to a 
temporary directory, in the absence of other input.

(Experience with pkg_resources' caching approach suggests that using 
the current directory or a home-directory-based location by default 
was a bad idea, at least without a fallback to a tempdir on write failure.)

Any thoughts?

___
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-archive.com

Re: [Python-Dev] [Distutils] PEP 365 (Adding the pkg_resources module)

[Kevin Turner]

On Wed, 2008-03-19 at 22:18 -0600, zooko wrote:
> 1.  "The very notion of package dependency resolution and  
> programmable or command-line installation of packages at the language  
> level is a bad notion."
> 
> This can't really be the case.  If the existence of such  
> functionality at the programming language level were an inherently  
> bad notion, then we would be hearing some complaints from the Ruby  
> folks, where the Gems system is standard and ubiquitous.  We hear no  
> complaints -- only murmurs of satisfaction.

Okay then, just to fill out your sample -- as the maintainer of a Python
library which is ported to Ruby, I complain equally about eggs and gems.
This isn't really the place for it, but as near as I can tell, the use
of gems requires you to know whether the user has installed your
dependency in the system install or through a gem *at the time you write
your code*, so you know whether to write "require 'dep'" or "require
'rubygems'; gem 'dep'".  This is, IMHO, even worse than the "setuptools
breaks PYTHONPATH" complaint you cited.

> Note that Ruby software is not too hard to include in operating  
> system packaging schemes -- my Ubuntu Hardy apt-cache shows plenty of  
> Ruby software.

Yes, but that software is not installed using the gem management system,
as I confirmed with a recent conversation with my package manager while
we were talking about http://bugs.debian.org/470282 , a quirk which was
hopefully a one-time API breakage, but certainly has not endeared me to
rubygems any further.

I'm sure we could find other people to complain if we look around a
little more.  I know I have commiserators out there.

But, stepping back a bit:

You're right in believing that it is neigh impossible to distribute Ruby
software without providing gems.  So much of your userbase expects it,
especially when you're distributing a library which their applications
will in turn depend on, because *their* users will expect gems, and they
need to be able to use gems to install the dependency.

setuptools seems to perform slightly better here, as, by merely making
sure my pypi entry has a reachable download_url, my package seems to be
available for installation by setuptools users.  Nonetheless, I get a
recurring stream of requests for egg distribution from people who
believe eggs have manifest destiny, and as we heard recently, that "the
controversy is over."

Meanwhile, I beg their continued forgiveness for being hesitant to
require my users to use something not in the standard library for
something as fundamental as "setup.py install."

These folks are the same who gave me bug reports when I put a .tar.bz2
link to my pypi entry, because apparently -- even though bz2 extraction
has been a feature of GNU tar for years -- setuptools (which uses the
standard library tarfile module) on some platforms cannot uncompress bz2
packages.  

the conclusion I am trying to reach here is this:

as a Python package maintainer, I have no idea what the hell to do to
satisfy my users, from those who are using python 2.3 and have no desire
for any new packaging or import semantics, to those who don't mind
having a new ez_setup downloaded on install.  The people who have found
advantages to using the egg-based distribution system are not going
away.  Providing something in the standard library will provide clear
guidance for me, and relieve me of the fear that I am pushing surprising
(.pth) or non-standard installation behavior on my users.

so, I hope you work something out.

Love,

 - Kevin

___
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-archive.com

Re: [Python-Dev] [Distutils] PEP 365 (Adding the pkg_resources module)

[Bill Janssen]

> although the word "trove" means nothing to me

http://www.askoxford.com/concise_oed/trove?view=uk

"a store of valuable or delightful things"

Bill
___
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-archive.com

Re: [Python-Dev] [Distutils] Capsule Summary of Some Packaging/Deployment Technology Concerns

[Alexander Michael]

On Wed, Mar 19, 2008 at 6:15 PM, Jeff Rush <[EMAIL PROTECTED]> wrote:
>  Frankly I'd like to see setuptools exploded, with those parts of general use
>  folded back into the standard library, the creation of a set of
>  non-implementation-specific documents of the distribution formats and
>  behavior, leaving a small core of one implementation of how to do it and the
>  door open for others to compete with their own implementation.

If I hazard an opinion seconding this sentiment. In my use of
setuptools, it definitely feels like it wants to be three (mostly)
independent projects:

1) The project that standardizes the concept now embodied by eggs and
provides the basic machinery to work with them (find them, introspect
metadata, "import" them, etc.), but not install them per se. This is
generally useful as common plug-in framework, if nothing else.
Currently, this "run-time support" functionality is in pkg_resources.
2) The tool you can use to build eggs (but not install them per se).
Currently this is the setuptools extension to distutils.
3) The tool for installing eggs (or their equivalent) and (optionally)
their dependencies (optionally using remote hosts) as well as
uninstalling. Currently this is easy_install (well, except for
uninstalling, which is understandable quite difficult).

Finally, there is the fourth and already separate project of PyPI:
4) The hosted repository of publicly available eggs (or their
equivalent). This should export any metadata required to resolve
dependencies relatively cheeply.

Breaking them apart will make it easier to have two separate projects
for building eggs (or their equivalents) -- one based on distutils and
the other replacing it. Even more importantly, it will make it
possible for multiple installers to be developed that scratch
particular itches. Hopefully one would eventually emerge as the
de-facto standard, but this will ultimately be decided by community
adoption.

Alex
___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Martin v. Löwis]

> I'll note that I use easy_install *only* to work in *non-system*
> locations:  if I want to install Python packages to /usr/lib/python2.x/,
> I use the standard system installer, e.g. 'apt-get install
> python-frobnatz'. 

This is probably not the Windows way of doing things (at least not how
I use Windows). Windows doesn't really have the notion of "system
location" (or multiple levels of them, where \Windows and 
\Windows\system32 is "more system" than \Program Files, say).

Windows users typically view the entire system as "theirs", and
have no concerns at all about putting things into Program Files,
system32, or, for that matter, \python25. In fact, they don't care
or even know where stuff ends up - they expect that the system will
find it, and they expect that they can remove anything they installed
even without known where it is - because there is a standard place
to look for uninstalling things.

Of course, setuptools is not the only piece of software that doesn't
play well, so Windows users collect all kinds of cruft over time.
Eventually, C: will run out of disk space, and they either get a
new machine, or reinstall from scratch.

> I wonder if a GUI for managing the add-ons would fit the bill, as an
> alternative to packaging them as though they were standalone programs?

On Windows, it is fairly easy to have an uninstaller registered. There
are wrappers to managing that (such as MSI), but it's really only a
set of registry keys that needs to get written on installation time,
one of them being the command to run on uninstallation.

Assuming that you uninstall the package before uninstalling Python, that
uninstall program could be a Python script (although using a cmd.exe
batch file would probably be more resilient).

The concern with "you just need to delete the folder" is "how am I
supposed to know that? and can I be really sure?". If you run the
official uninstall procedure, and it messes things up, you can complain
to setuptools, or the package author that uninstallation "doesn't work".

If you delete stuff manually, and you forgot to remove something in
a remote location you didn't even know it existed, you still think
it's your own fault. So people are hesitant to actually execute the
procedure.

Of course, once you *do* provide an entry to "Add/Remove Programs",
uninstalling won't be mere deletion, as mere deletion would still
leave these registry keys behind (although Windows got more resilient
over time to provide cleanup in that case: I believe it offers to
remove the ARP entry if the uninstall program has been removed)


Regards,
Martin
___
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-archive.com

Re: [Python-Dev] platform management

[Martin v. Löwis]

> Looking at http://docs.python.org/lib/module-os.html, I find the following:
> 
>   name
>   
> The name of the operating system dependent module imported. The
> following names have currently been registered: 'posix', 'nt', 'mac',
> 'os2', 'ce', 'java', 'riscos'.
> 
> This implies that there's a registry somewhere?

This is actually the list of names that the "os" module may take.
There are different implementations of the os module, so instead of
"import os", you could write "import posix", "import nt", "import ce"
(assuming you run on one of these systems).

So it really has not much to do with the name of the operating system,
but rather with the name Python gives to the API.

Regards,
Martin
___
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-archive.com

Re: [Python-Dev] Trove classifiers

[Fred Drake]

On Mar 20, 2008, at 11:55 AM, Oleg Broytmann wrote:
>   Yes, exactly. Eric Raymond claims to be the inventor, but there are
> different voices against him:
> http://damagestudios.net/blog/2005/08/15/sourceforge-founders


That contests that Raymond was an "architectural granddaddy of  
SourceForge", not that he invented Trove.  My understanding is that he  
did start the efforts to define the Trove classifiers as part of a  
larger effort that never panned out, but that defining the classifiers  
was not a solo effort.


   -Fred

-- 
Fred Drake   




___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Martin v. Löwis]

> Actually, if someone were to develop a patch for PyPI to do this, we 
> could perhaps have a "display download dependencies" link for eggs 
> shown on PyPI.  That way, someone who wants to do a manual download 
> could get a page with links for all the required eggs, and manually 
> download them.

Just to make this position a bit more official (as one of the PyPI
maintainers): it would be fully within the scope of PyPI to integrate
dependency tracking into its database, and present it in any form
that is desired. Any such feature would have to be contributed.

Regards,
Martin

___
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-archive.com

Re: [Python-Dev] 2to3 and print function

[David Wolever]

On 20-Mar-08, at 2:15 AM, Guido van Rossum wrote:
> On Wed, Mar 19, 2008 at 10:27 PM, David Wolever  
> <[EMAIL PROTECTED]> wrote:
>>  Why not, instead of trying both parsers, scan for a __future__
>>  import, then do the Right Thing based on that?
> Different use cases.
> Auto-detection based on __future__ would be a good thing to have
> (assuming that __future__ statement has actually been implemented :-).
The __future__ statement has been implemented, so __future__ auto- 
detection will come shortly :)
___
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-archive.com

Re: [Python-Dev] Checking for the -3 flag from Python code

[Nick Coghlan]

Steven Bethard wrote:
> On Wed, Mar 19, 2008 at 5:51 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> This flag is exposed to python code as sys.flags.py3k_warning
>>
>>  So the hack added to some of the test code that I saw go by on
>>  python-checkins isn't needed :)
> 
> Excellent.  I asked around at the sprints and everyone thought it was
> unexposed.  If no one else has already done it, I'll remove the hacks
> from test_py3kwarn and the regrtest skipping mechanism.

Brett's subsequent checkin pointed out that that particular flag is 
exposed even more directly as sys.py3kwarning, in addition to being 
accessible via the general 'command line flags' object.

The downside of the module level attribute is that it gives the illusion 
of being writable without actually having any effect when writing to it. 
The inconsistent spelling between sys.py3kwarning and 
sys.flags.py3k_warning is also a minor irritation - are we actually 
gaining anything by having both mechanisms for accessing the flag value?

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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-archive.com

Re: [Python-Dev] Improved thread switching

[Facundo Batista]

2008/3/20, Andrew McNabb <[EMAIL PROTECTED]>:

> Since we officially encourage people to spawn processes instead of
>  threads, I think that this would be a great idea.  The processing module
>  has a similar API to threading.  It's easy to use, works well, and most
>  importantly, gives us some place to point people to when they complain
>  about the GIL.

I'm +1 to include the processing module in the stdlib.

just avoid confussions, with these libraries with alike names, I'm
meaning this [1] module, the one that emulates the semantics of
threading module.

Does anybody has strong reasons for this module to not get included?

Regards,

[1] http://pypi.python.org/pypi/processing

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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-archive.com

Re: [Python-Dev] Consistent platform name for 64bit windows (was: distutils.util.get_platform() for Windows)

[M.-A. Lemburg]

On 2008-03-20 13:55, M.-A. Lemburg wrote:
> On 2008-03-20 13:42, Thomas Heller wrote:
>> M.-A. Lemburg schrieb:
>>> About the platform.py changes: if someone could provide the return
>>> values of sys.getwindowsversion() for 64bit versions of Windows
>>> XP and Vista, I could add support for it (don't have a 64bit version
>>> of Windows available to check myself).
>> This is the output of a 32-bit Python running on "Windows XP Professional
>> x64 Edition, Version 2003, Service Pack 2":
>>
>> C:\Python24>ver
>>
>> Microsoft Windows [Version 5.2.3790]
>>
>> C:\Python24>python
>> Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on 
>> win32
>> Type "help", "copyright", "credits" or "license" for more information.
> import sys
> sys.getwindowsversion()
>> (5, 2, 3790, 2, 'Service Pack 2')
> 
> Thank you !
> 
> Anyone with a 64bit Vista ?
> 
> Or even better: a page documenting what to expect from the system call
> behind the sys.getwindowsversion() API ?

FYI: I added winreg and sys.getwindowsversion() support in r61674.

platform.machine() and .processor() will now use the environment
variables PROCESSOR_ARCHITECTURE and PROCESSOR_IDENTIFIER where
available (should work on Windows XP and later).

According to http://support.microsoft.com/kb/888731 platform.machine()
will return "AMD64", so I guess the "x64" string is just a marketing
name for 64-bit platforms on Windows and the underlying system uses
"AMD64" as machine type name.

For x86 processors, you'll now get "x86" on Windows XP and later.

For Itanium processors, you should get "IA64" according to this
WOW64 page:

http://msdn2.microsoft.com/en-us/library/aa384274(VS.85).aspx

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 20 2008)
 >>> Python/Zope Consulting and Support ...http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
___
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-archive.com

Re: [Python-Dev] Improved thread switching

[Jesse Noller]

Even I, as a strong advocate for it's inclusion think I should finish
the PEP and outline all of the questions/issues that may come out of
it.

On Thu, Mar 20, 2008 at 1:37 PM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
> 2008/3/20, Andrew McNabb <[EMAIL PROTECTED]>:
>
>
>  > Since we officially encourage people to spawn processes instead of
>  >  threads, I think that this would be a great idea.  The processing module
>  >  has a similar API to threading.  It's easy to use, works well, and most
>  >  importantly, gives us some place to point people to when they complain
>  >  about the GIL.
>
>  I'm +1 to include the processing module in the stdlib.
>
>  just avoid confussions, with these libraries with alike names, I'm
>  meaning this [1] module, the one that emulates the semantics of
>  threading module.
>
>  Does anybody has strong reasons for this module to not get included?
>
>  Regards,
>
>  [1] http://pypi.python.org/pypi/processing
>
>  --
>  .Facundo
>
>  Blog: http://www.taniquetil.com.ar/plog/
>  PyAr: http://www.python.org/ar/
>
>
> ___
>  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/jnoller%40gmail.com
>
___
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-archive.com

Re: [Python-Dev] Improved thread switching

[Nick Coghlan]

Facundo Batista wrote:
> 2008/3/20, Andrew McNabb <[EMAIL PROTECTED]>:
> 
>> Since we officially encourage people to spawn processes instead of
>>  threads, I think that this would be a great idea.  The processing module
>>  has a similar API to threading.  It's easy to use, works well, and most
>>  importantly, gives us some place to point people to when they complain
>>  about the GIL.
> 
> I'm +1 to include the processing module in the stdlib.
> 
> just avoid confussions, with these libraries with alike names, I'm
> meaning this [1] module, the one that emulates the semantics of
> threading module.
> 
> Does anybody has strong reasons for this module to not get included?

Other than the pre-release version number and the fact that doing such a 
thing would require R. Oudkerk to actually make the offer rather than 
anyone else? There would also need to be the usual thing of at least a 
couple of people stepping up and being willing to maintain it.

I also wouldn't mind seeing some performance figures for an application 
that was limited to making good use of only one CPU when run with the 
threading module, but was able to exploit multiple processors to obtain 
a speed improvements when run with the processing module.

That said, I'm actually +1 on the general idea, since I always write my 
threaded Python code using worker threads that I communicate with via 
Queue objects. Pyprocessing would be a great way for me to scale to 
multiple processors if I was running CPU intensive tasks rather than 
potentially long-running hardware IO operations (I've been meaning to 
check it out for a long time, but have never actually needed to for 
either work or any home projects).

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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-archive.com

Re: [Python-Dev] The Breaking of distutils and PyPI for Python 3000?

[Stephen J. Turnbull]

"Martin v. Löwis" writes:

 > I don't think any of the core committers is qualified to write such
 > a document. Instead, it would have to be written by people who
 > *actually* ported a project from 2 to 3 in some form.

Note that this is precisely the kind of experience Skip Montanaro is
talking about trying to generate in the context of SpamBayes in a
thread on the python-3000 list entitled "Strategy for porting to 3.0?"
I don't know if he plans to write a HOWTO himself, but he certainly
intends to keep a lab notebook that will be of help in writing such a
document.

___
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-archive.com

Re: [Python-Dev] The Breaking of distutils and PyPI for Python 3000?

[Collin Winter]

On Wed, Mar 19, 2008 at 6:17 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> You seem to be implying that some projects may release separate
>  >> source distributions. I cannot imagine why somebody would want to
>  >> do that.
>  >
>  > That's odd. I can't imagine why anybody would *not* want to do that.
>  > Given the number of issues 2to3 can't fix (because it would be too
>  > dangerous to guess)
>
>  Like which one specifically?

Anything having to do with the str->bytes/unicode->str move is so far
off-limits to 2to3.

Collin Winter
___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Steve Holden]

Martin v. Löwis wrote:
Martin v. Löwis wrote:
>> I'll note that I use easy_install *only* to work in *non-system*
>> locations:  if I want to install Python packages to /usr/lib/python2.x/,
>> I use the standard system installer, e.g. 'apt-get install
>> python-frobnatz'. 
> 
> This is probably not the Windows way of doing things (at least not how
> I use Windows). Windows doesn't really have the notion of "system
> location" (or multiple levels of them, where \Windows and 
> \Windows\system32 is "more system" than \Program Files, say).
> 
> Windows users typically view the entire system as "theirs", and
> have no concerns at all about putting things into Program Files,
> system32, or, for that matter, \python25. In fact, they don't care
> or even know where stuff ends up - they expect that the system will
> find it, and they expect that they can remove anything they installed
> even without known where it is - because there is a standard place
> to look for uninstalling things.
> 
> Of course, setuptools is not the only piece of software that doesn't
> play well, so Windows users collect all kinds of cruft over time.
> Eventually, C: will run out of disk space, and they either get a
> new machine, or reinstall from scratch.
> 
>> I wonder if a GUI for managing the add-ons would fit the bill, as an
>> alternative to packaging them as though they were standalone programs?
> 
> On Windows, it is fairly easy to have an uninstaller registered. There
> are wrappers to managing that (such as MSI), but it's really only a
> set of registry keys that needs to get written on installation time,
> one of them being the command to run on uninstallation.
> 
> Assuming that you uninstall the package before uninstalling Python, that
> uninstall program could be a Python script (although using a cmd.exe
> batch file would probably be more resilient).
> 
> The concern with "you just need to delete the folder" is "how am I
> supposed to know that? and can I be really sure?". If you run the
> official uninstall procedure, and it messes things up, you can complain
> to setuptools, or the package author that uninstallation "doesn't work".
> 
> If you delete stuff manually, and you forgot to remove something in
> a remote location you didn't even know it existed, you still think
> it's your own fault. So people are hesitant to actually execute the
> procedure.
> 
> Of course, once you *do* provide an entry to "Add/Remove Programs",
> uninstalling won't be mere deletion, as mere deletion would still
> leave these registry keys behind (although Windows got more resilient
> over time to provide cleanup in that case: I believe it offers to
> remove the ARP entry if the uninstall program has been removed)
> 
> 
> Regards,
> Martin
> ___
> 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/python-python-dev%40m.gmane.org
> 

>> I'll note that I use easy_install *only* to work in *non-system*
>> locations:  if I want to install Python packages to /usr/lib/python2.x/,
>> I use the standard system installer, e.g. 'apt-get install
>> python-frobnatz'. 
> 
> This is probably not the Windows way of doing things (at least not how
> I use Windows). Windows doesn't really have the notion of "system
> location" (or multiple levels of them, where \Windows and 
> \Windows\system32 is "more system" than \Program Files, say).
> 
> Windows users typically view the entire system as "theirs", and
> have no concerns at all about putting things into Program Files,
> system32, or, for that matter, \python25. In fact, they don't care
> or even know where stuff ends up - they expect that the system will
> find it, and they expect that they can remove anything they installed
> even without known where it is - because there is a standard place
> to look for uninstalling things.
> 
In point of fact, for an *end user* it makes increasing sense to use 
application installers that automatically install a correct-version 
interpreter and all dependencies in a stand-alone manner (i.e. 
explicitly *not* sharing anything with any other installed application.

This makes uninstall much easier, as the lack of external dependencies 
eases version lock-step problems.

It would pain me, as a computer scientist, to do this, but I honestly 
believe it may be the way forward -- just think, it wouldn't even matter 
whether an application (and all its extension modules) had been built 
with VS2003, VS2008 or Mingw.

People misunderstood when Mike Driscoll started to provide pure-Python 
modules as Windows installers, but increasingly your naive Windows 
programmer is going to be happier doing that. I'm not sure whether that 
provides easy_f**king_uninstall (Zed Shaw will live on in my memory for 
that particular PyCon moment), but it (ought to be) relatively easy to 
do so. Extension modules for programmers still off

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Phillip J. Eby]

At 05:55 PM 3/20/2008 +, Paul Moore wrote:
>It's not that I object to the existence of automatic dependency
>management, I object to being given no choice, as if my preference for
>handling things manually is unacceptable.

Note that easy_install has a --no-deps option, and you can make it 
the default in your distutils.cfg file.

Also, setuptools-based packages *can* build bdist_wininst 
installers.  (In fact, if memory serves, I added that feature at your request.)

Personally, I'm not very thrilled with the number of complaints on 
this thread that could be resolved by RTFMing.  There are extensive 
manuals, and they do contain the information that some people are 
saying isn't there.  In several cases that I've seen here today 
alone, there are actually *entries in the tables of contents* that 
name the precise thing people here are characterizing as undocumented 
or even *impossible*, like:

* Making your package available for EasyInstall
* Installing on Un-networked Machines
* Custom Installation Locations
* Restricting Downloads with --allow-hosts

It's easy to get the impression that people not only didn't RTFM, 
they didn't even Read The Friendly Table Of Contents of the said 
M.  Nor, when, they found something in the manual that they didn't 
understand, write to the distutils-sig to ask anybody to explain, and 
perhaps suggest ways the FM's could be improved.

___
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-archive.com

[Python-Dev] Python source code on Bazaar vcs

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm happy to announce that we now have available for public  
consumption, the Python source code for 2.5, 2.6 and 3.0 available  
under the Bazaar distributed version control system.

The current Subversion repository is still the master copy of the  
source code.  We have not made a decision to move to Bazaar  
officially, nor have we made a decision to even move off of  
Subversion.  We're making these branches available exactly so that  
you, the Python developer community, can kick the tires and see if it  
makes sense to move to a different vcs.  Nothing will happen until  
after the Python 2.6/3.0 releases anyway.

All the gory details are documented here:

 http://www.python.org/dev/bazaar

These branches are available both for core Python developers with  
commit privileges, and the wider world of developers without commit  
privileges.  It's this latter group that I think will find the most  
compelling immediate benefit from using Bazaar, because they will no  
longer need to maintain their own changes using a mass of patch files.

For more information on Bazaar in general, see:

 http://bazaar-vcs.org

You will probably be most interested in the Bazaar mirrors of the  
Subversion master repository.  We have a cron job that updates Bazaar  
from Subversion every 15 minutes.  It is also possible to push changes  
made in your Bazaar branches into the Subversion master, so you can  
keep reasonably up-to-date and interact with the Python source code  
solely via Bazaar.

Please let me know if you have any questions or anything in the docs  
referenced above aren't clear.  I know I need to document the Bazaar- 
 >Subversion workflow in more detail.

Huge thanks go out especially to Thomas Wouters who sprinted with me  
yesterday on getting the whole infrastructure up and running.  Thanks  
also to Martin v. Loewis, Sean Reifschneider, and the folks here at  
Pycon from the Bazaar project, Ian, Andrew, John, and Edwin.

Enjoy,
- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+K+H3EjvBPtnXfVAQL6bwP/d0XKx0mRPgzdOD6zCPwwRl8y2kxWV9Vl
zVwN07cK8IlwMa9M470MsERuXuD8hmeXnPgnrUcrX9HciwldmY8C33t0f8GaOk1J
iD4Od1midlIaJJiMd+JcFk9NbX3Rwc4HMj3s8jKjjdlGrFe77ei9DCZ/HMl/iG5K
fyyjXo4HLEE=
=Gcjq
-END PGP SIGNATURE-
___
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-archive.com

[Python-Dev] Could someone please review patch 799428: fix Tkinter tk_focusNext?

[Russell E. Owen]

Patch  is a trivial fix to a 
long-standing issue with Tkinter: calls to the widget method 
tk_focusNext() fail with "unsubscriptable object" error.

Also issue 1068881  can be closed. 
This is a case where procrastination paid off.

Regards,

-- Russell

___
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-archive.com

Re: [Python-Dev] The Breaking of distutils and PyPI for Python 3000?

[Martin v. Löwis]

 You seem to be implying that some projects may release separate
>>  >> source distributions. I cannot imagine why somebody would want to
>>  >> do that.
>>  >
>>  > That's odd. I can't imagine why anybody would *not* want to do that.
>>  > Given the number of issues 2to3 can't fix (because it would be too
>>  > dangerous to guess)
>>
>>  Like which one specifically?
> 
> Anything having to do with the str->bytes/unicode->str move is so far
> off-limits to 2to3.

Sure - but does that mean you need to separate code bases?

Why does this move prevent people from running the same
code in 2.x and 3.x? In 2.x, they should use Unicode objects
for text and regular strings for binary data, and such code
will run fine after converted by 2to3.

Regards,
Martin
___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Paul Moore]

On 20/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 05:55 PM 3/20/2008 +, Paul Moore wrote:
>  >It's not that I object to the existence of automatic dependency
>  >management, I object to being given no choice, as if my preference for
>  >handling things manually is unacceptable.
>
> Note that easy_install has a --no-deps option, and you can make it
>  the default in your distutils.cfg file.

Sorry, I wasn't clear. There's context that helps, but even with it I
wasn't clear. Tres told me how to download all the dependencies for
use offline (which I actually knew, but that's not the point here). I
clarified that I didn't want to use dependency management but
preferred to manage dependencies manually.

I then went on to say that putting dependency information in setup.exe
and expecting users to use automatic dependency resolution encourages
developers to omit dependency details from documentation (to an extent
I can't quantify, but I believe is non-zero). That lack of
documentation "forces" me to rely on the automatic process. THAT is
the thing that removes my choice, not easy_install's ability to skip
dependency checking.

I'm sorry I wasn't clearer - but in my defence, my posting was pretty
long already and I was trying to be brief...

>  Also, setuptools-based packages *can* build bdist_wininst
>  installers.  (In fact, if memory serves, I added that feature at your 
> request.)

I know. python setup.py bdist_wininst. And thank you for adding it.
But again you miss my point. People are starting to omit distributing
bdist_wininst installers in favour of eggs only. And you cannot (to my
knowledge) convert an egg into a bdist_wininst installer, and if you
can't compile from source (a C extension with complex dependencies,
for example) you're stuck (in the sense that you're forced to use eggs
without add/remove programs support).

>  Personally, I'm not very thrilled with the number of complaints on
>  this thread that could be resolved by RTFMing.  There are extensive
>  manuals, and they do contain the information that some people are
>  saying isn't there.  In several cases that I've seen here today
>  alone, there are actually *entries in the tables of contents* that
>  name the precise thing people here are characterizing as undocumented
>  or even *impossible*, like:
>
>  * Making your package available for EasyInstall
>  * Installing on Un-networked Machines
>  * Custom Installation Locations
>  * Restricting Downloads with --allow-hosts
>
>  It's easy to get the impression that people not only didn't RTFM,
>  they didn't even Read The Friendly Table Of Contents of the said
>  M.  Nor, when, they found something in the manual that they didn't
>  understand, write to the distutils-sig to ask anybody to explain, and
>  perhaps suggest ways the FM's could be improved.

As I said, I know there is documentation, but (a) it's very long, and
(b) it's full of jargon that you need to understand before you can
follow it. Believe me, I've tried to read it.

But ultimately, all I'm trying to do is work out how to do something
that is as simple as "download exe, run it" (on a PC with browser-only
access to the internet) in the bdist_wininst world. That's all. I'm
equally not very thrilled at having to read many pages of dense
documentation to find out how to do this. Heck, I read the
documentation twice, and asked on the distutils-sig, before I worked
out how to do easy_install -zmax (and the only reason I can remember
that now without looking it up is that "zmax" is memorable - z plus
the word max - I have no idea without going back to the manual what
the individual options do). I'd say that the documentation needs to be
better. (And I said how - a tutorial-style summary. What more should I
do short of writing it myself?)

Honestly, I'm trying to help improve (by my measure of improvement,
certainly) setuptools. I've done as much (more!) homework as I feel is
appropriate (no, I haven't studied the whole manual all the way
through). Being treated as if it's my fault, and I haven't done
enough, is both discouraging and to be honest, somewhat offensive.

I'm going to quit this thread for a while now, as I don't want to turn
things into a flamewar. I believe Tres took my points on board. I hope
others have, too. I certainly don't expect everything I say to be
taken as gospel, so that's enough for now.

Paul.
___
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-archive.com

Re: [Python-Dev] The Breaking of distutils and PyPI for Python 3000?

[Bob Kline]

Martin v. Löwis wrote:
>> Anything having to do with the str->bytes/unicode->str move is so far
>> off-limits to 2to3.
>> 
>
> Sure - but does that mean you need to separate code bases?
>
> Why does this move prevent people from running the same
> code in 2.x and 3.x? In 2.x, they should use Unicode objects
> for text and regular strings for binary data, and such code
> will run fine after converted by 2to3.
>   

Not if it includes code that looks like this:

if type(response) in (str, unicode): .

and it's really true that "[a]nything having to do with the 
str->bytes/unicode->str move is so far off-limits" to the upgrade tool.

-- 
Bob Kline
http://www.rksystems.com
mailto:[EMAIL PROTECTED]

___
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-archive.com

Re: [Python-Dev] Python source code on Bazaar vcs

[Christian Heimes]

Barry Warsaw schrieb:
> I'm happy to announce that we now have available for public  
> consumption, the Python source code for 2.5, 2.6 and 3.0 available  
> under the Bazaar distributed version control system.

Thank you very much to Barry and the rest of team! Great work!

Ubuntu users have to install a newer version of bzr before they can 
check out the sources:

sudo vi /etc/apt/sources.list.d/bzr.list
--- add ---
deb http://ppa.launchpad.net/bzr/ubuntu gutsy main
deb-src http://ppa.launchpad.net/bzr/ubuntu gutsy main
--- eof ---

sudo apt-get update

#  --force-yes because the packages aren't signed yet
sudo apt-get --force-yes -y install bzr bzr-gtk bzrtools


Also read https://launchpad.net/~bzr/+archive and 
http://bazaar-vcs.org/DistroDownloads

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-archive.com

Re: [Python-Dev] [Distutils] PEP 365 (Adding the pkg_resources module)

[Paul Moore]

On 19/03/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'd only do what __loader__ offers. People can always wrap a StringIO around 
> it.
>
>  >  Once I have a patch, I'll post it to the tracker. What's the best
>  >  approach? Code a patch for 3.0 and backport, or code for 2.6 and let
>  >  the merging process do its stuff?
>
> Code for 2.6, let the merge do its thing.

http://bugs.python.org/issue2439

Let me know if you want any changes. If it's OK, I'll think about
whether grander things would be of use.

Paul.
___
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-archive.com

[Python-Dev] svnmerge and added files

[Martin v. Löwis]

It seems that recently, a number of merges broke in the sense
that files added to the trunk were not merged into the
3k branch.

Is that a general problem with svnmerge? Should that be
fixed to automatically do a "svn add" when merging changes
that included file additions and removals?

Regards,
Martin
___
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-archive.com

Re: [Python-Dev] Python source code on Bazaar vcs

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mar 20, 2008, at 3:58 PM, Christian Heimes wrote:

> Barry Warsaw schrieb:
>> I'm happy to announce that we now have available for public   
>> consumption, the Python source code for 2.5, 2.6 and 3.0 available   
>> under the Bazaar distributed version control system.
>
> Thank you very much to Barry and the rest of team! Great work!
>
> Ubuntu users have to install a newer version of bzr before they can  
> check out the sources:
>
> sudo vi /etc/apt/sources.list.d/bzr.list
> --- add ---
> deb http://ppa.launchpad.net/bzr/ubuntu gutsy main
> deb-src http://ppa.launchpad.net/bzr/ubuntu gutsy main
> --- eof ---
>
> sudo apt-get update
>
> #  --force-yes because the packages aren't signed yet
> sudo apt-get --force-yes -y install bzr bzr-gtk bzrtools
>
>
> Also read https://launchpad.net/~bzr/+archive and 
> http://bazaar-vcs.org/DistroDownloads

Thanks Christian, I'll add this to the page.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+LT2nEjvBPtnXfVAQJ+aAP+JNqjnGdgfqszSGDn8dtBppaxf4d486DD
5GLdPUn696nHw0Q2+OzqFbTk8s/qNDyNmVoLuG80TsyrhqMJTidIwyupjxFXvdfI
gk/7Ghl1/ky5QEBXfmE0xrql+uoEmoVD+OVxlrzYy8Z9rm22y0EAUN2BOyM9oLYq
TsSj2XJSdVM=
=XJlg
-END PGP SIGNATURE-
___
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-archive.com

Re: [Python-Dev] Python source code on Bazaar vcs

[Ralf Schmitt]

On Thu, Mar 20, 2008 at 8:42 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'm happy to announce that we now have available for public
> consumption, the Python source code for 2.5, 2.6 and 3.0 available
> under the Bazaar distributed version control system.
>

I have also setup a mirror using mercurial: http://hgpy.de/py/
It contains the 2.4, 2.5, trunk and py3k branches (in case anyone wants to
compare this to bzr).
___
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-archive.com

Re: [Python-Dev] svnmerge and added files

[Christian Heimes]

Martin v. Löwis schrieb:
> It seems that recently, a number of merges broke in the sense
> that files added to the trunk were not merged into the
> 3k branch.
> 
> Is that a general problem with svnmerge? Should that be
> fixed to automatically do a "svn add" when merging changes
> that included file additions and removals?

It sometimes happens when I do a svnmerge, revert the merge with svn 
revert -R and do a second svnmerge. Files added by the first svnmerge 
aren't added to the commit list for the second merge. Unfortunately 
svnmerge.py doesn't warn me when the file already exists.

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-archive.com

Re: [Python-Dev] The Breaking of distutils and PyPI for Python 3000?

[Martin v. Löwis]

> Not if it includes code that looks like this:
> 
>if type(response) in (str, unicode): .
> 
> and it's really true that "[a]nything having to do with the 
> str->bytes/unicode->str move is so far off-limits" to the upgrade tool.

Depends on what the purpose of the test is. If it tests for
"is response text", then 2to3 will work just fine on it, converting
it to

if type(response) in (str, str):

This is redundant, but correct.

Regards,
Martin

___
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-archive.com

Re: [Python-Dev] [Distutils] PEP 365 (Adding the pkg_resources module)

[Jeff Rush]

Paul Moore wrote:
> On 20/03/2008, zooko <[EMAIL PROTECTED]> wrote:

> I'll chime in here, too. I really want to like
> setuptools/easy_install, but I don't. I'll try to be specific in my
> reasons, in the hope that they can be addressed. I know some of these
> are "known about", but one of my meta-dislikes of setuptools is that
> known issues never seem to get addressed (I know, patches accepted,
> but I haven't got the time either...)

Clearly explained problems with the existing arrangement is valuable as well 
as patches.  Thanks for taking the time to help us see your viewpoint.


> 1. No integration with the system packager (Windows, in my case). If I
> do easy_install nose, then nose does not show up in add/remove
> programs. That significantly affects the way I manage my PC.

Part of this stems from stretching of the original mission of setuptools, to 
install modules for Python, into a general-purpose application installation 
tool.  The buildout tool is more suited for application installation, although 
not ideal yet.

In your scenario, what happens when one egg pulls in another and another, 
until you have a hundred entries in your add/remove menu?  And you don't 
understand the inter-relationship of those so you cannot do a clean uninstall?

Similarly, or what do you want to appear in that add/remove menu when you are 
using independent sandboxes with various applications in them, some of which 
are accessible only to specific users who are not admins on that box?


> 3. The pkg_resources documentation (in particular, that's the one I've
> tried to follow) is extremely hard to read. Partly this is just style,
> but it's partly because it is couched in very unfamiliar terms
> (distributions, working sets, interfaces, providers, etc). It's also
> *huge*. A tutorial style overview, supported by API detail, would be
> far better.

We'll get better docs.  Of course, that module contains roughly five different 
sets of functionality, some of which can be used unrelated to the others so 
it's not just one API.


> 4. Hard to use with limited connectivity. At work, I *only* have
> access to the internet via Internet Explorer (MS based proxy). There
> are workarounds, but ultimately "download an installer, then run it"
> is a far simpler approach for me.

This is hard to address using independent eggs re setuptools but fits buildout 
which provides for deployment of a set of related eggs as a single entity. 
I'll add it as a use case and see what we can do though.


> 5. Auto-discovery doesn't always work. I'm sorry, I really can't
> recall the example at the moment, but sometimes easy_install says it
> can't find a package I *know* is available.

I've hit a few of these myself, although it wasn't an issue with the 
auto-discovery mechanism but rather quality problems with PyPI itself.  Some 
of the eggs only had binary distributions provided, and they were not for my 
platform so couldn't be used.  Better error messages in this area would help, 
with encouragement to nag the original author to provide better data on PyPI.


> 6. Splitting the community. Windows users rely heavily on binary
> installers (at least, I do). We're starting to get a situation where
> some projects provide .egg files, and some provide traditional
> (bdist_wininst/bdist_msi) installers. This is bad. One way to do it,
> and all that :-)

Reporting and author nagging facilities built into PyPI could help encourage 
more consistent behavior.

-Jeff

___
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-archive.com

Re: [Python-Dev] Python source code on Bazaar vcs

[Christian Heimes]

Barry Warsaw schrieb:
> I'm happy to announce that we now have available for public
> consumption, the Python source code for 2.5, 2.6 and 3.0 available
> under the Bazaar distributed version control system.

Somebody has to fix the subversion related code in Python/sysmodule.c:

[EMAIL PROTECTED]:~/dev/python/bzr/trunk$ ./python
Fatal Python error: subversion keywords missing
Aborted (core dumped)

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-archive.com

Re: [Python-Dev] The Breaking of distutils and PyPI for Python 3000?

[Bob Kline]

Martin v. Löwis wrote:
>
>> Not if it includes code that looks like this:
>>
>>if type(response) in (str, unicode): .
>>
>> and it's really true that "[a]nything having to do with the 
>> str->bytes/unicode->str move is so far off-limits" to the upgrade tool.
>
> Depends on what the purpose of the test is. If it tests for
> "is response text", then 2to3 will work just fine on it, converting
> it to
>
> if type(response) in (str, str):

Then I'm taking him too literally, when he writes that the tool won't 
touch *anything* that has to do with the str->bytes/unicode->str move (I 
assumed that meant it wouldn't touch "unicode" in the snippet I gave 
above), right?

Will the tool also make the following work correctly?

if type(s) is str: s = unicode(s, 'utf-8')

-- 
Bob Kline
http://www.rksystems.com
mailto:[EMAIL PROTECTED]

___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Phillip J. Eby]

At 08:34 PM 3/20/2008 +, Paul Moore wrote:
>I then went on to say that putting dependency information in setup.exe
>and expecting users to use automatic dependency resolution encourages
>developers to omit dependency details from documentation (to an extent
>I can't quantify, but I believe is non-zero). That lack of
>documentation "forces" me to rely on the automatic process. THAT is
>the thing that removes my choice, not easy_install's ability to skip
>dependency checking.

Ah.  Fair enough.  So, if we get PyPI to display that information, 
that should fix this problem for you?


>People are starting to omit distributing
>bdist_wininst installers in favour of eggs only.

You mean, they're shipping a .win32.egg, but not an .exe?


>  And you cannot (to my
>knowledge) convert an egg into a bdist_wininst installer,

Not at the moment, no.  It seems like it ought to be *possible*, 
though, since the reverse translation can be done.  Eggs are more 
restrictive in what they can include, so the reverse step actually 
ought to be relatively easy.  Indeed, I would think that  it could be 
done by a standalone tool without even using setuptools.  All that 
really needs to happen (I believe) is that the zipfile directory 
needs all its names prepended with PURELIB or PLATLIB, and then add 
the appropriate prefix .exe and bdist_wininst extra data on the front 
of the restructured zip file.

In fact, it should probably be possible to write such a tool by 
subclassing the distutils bdist_wininst command and overriding the 
run() and get_inidata() methods, using the existing create_exe() 
method to do that part of the magic.

The other tool that would be handy to have, would be one that unpacks 
eggs into standard distutils-style installation.



> >  Personally, I'm not very thrilled with the number of complaints on
> >  this thread that could be resolved by RTFMing.
>...
>Honestly, I'm trying to help improve (by my measure of improvement,
>certainly) setuptools. I've done as much (more!) homework as I feel is
>appropriate (no, I haven't studied the whole manual all the way
>through). Being treated as if it's my fault, and I haven't done
>enough, is both discouraging and to be honest, somewhat offensive.

My comment wasn't aimed specifically at you; you're only one of many 
people today who have appeared to state that something or other 
wasn't possible or documented, described optional behavior as 
required, etc.  Addressing each and every one point by point looks 
petty, but then lumping them together like that makes it look like 
I'm picking on you specifically.  Sorry about that.

In any event, I'm not saying that anyone hasn't done enough or that 
it's their fault.  The fact that I'm not thrilled about some of the 
things said in the thread doesn't somehow magically invalidate other 
people's frustrations, nor was it my intent to accuse you (or anyone) 
of making up their problems.  I'm just expressing *my* frustration.

___
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-archive.com

Re: [Python-Dev] [Distutils] PEP 365 (Adding the pkg_resources module)

[Paul Moore]

On 20/03/2008, Jeff Rush <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
>  > On 20/03/2008, zooko <[EMAIL PROTECTED]> wrote:
>  > 1. No integration with the system packager (Windows, in my case). If I
>  > do easy_install nose, then nose does not show up in add/remove
>  > programs. That significantly affects the way I manage my PC.
>
>
> Part of this stems from stretching of the original mission of setuptools, to
>  install modules for Python, into a general-purpose application installation
>  tool.  The buildout tool is more suited for application installation, 
> although
>  not ideal yet.
>
>  In your scenario, what happens when one egg pulls in another and another,
>  until you have a hundred entries in your add/remove menu?  And you don't
>  understand the inter-relationship of those so you cannot do a clean 
> uninstall?

I don't let it. As I've said elsewhere, I prefer to manage
dependencies myself, manually.

Anything with that many dependencies shouldn't be using the system
Python, in my view. It should be packaged as a standalone application
(py2exe style) and as such have a single add/remove entry (and no
effect on the system Python).

>  Similarly, or what do you want to appear in that add/remove menu when you are
>  using independent sandboxes with various applications in them, some of which
>  are accessible only to specific users who are not admins on that box?

Independent sandboxes isn't a concept I can relate to under Windows.
That doesn't mean it's not possible (I don't know if it is) I just
don't have any useful comment to make, beyond saying that I personally
don't care what happens in that situation.

Paul.
___
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-archive.com

Re: [Python-Dev] The Breaking of distutils and PyPI for Python 3000?

[Martin v. Löwis]

>> if type(response) in (str, str):
> 
> Then I'm taking him too literally, when he writes that the tool won't 
> touch *anything* that has to do with the str->bytes/unicode->str move (I 
> assumed that meant it wouldn't touch "unicode" in the snippet I gave 
> above), right?

It definitely replaces unicode->str in this fragment.

> Will the tool also make the following work correctly?
> 
>if type(s) is str: s = unicode(s, 'utf-8')

It outputs

if type(s) is str: s = str(s, 'utf-8')

This is probably not correct. However, in 2.6, you could write
that as

if type(s) is bytes: s = unicode(s, 'utf-8')

as bytes is str in 2.6. If you want to support even older
versions, do

try:
bytes
except NameError:
bytes = str

somewhere, then write the code as I proposed above.

Regards,
Martin
___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[M.-A. Lemburg]

On 2008-03-20 21:34, Paul Moore wrote:
>>  Also, setuptools-based packages *can* build bdist_wininst
>>  installers.  (In fact, if memory serves, I added that feature at your 
>> request.)
> 
> I know. python setup.py bdist_wininst. And thank you for adding it.
> But again you miss my point. People are starting to omit distributing
> bdist_wininst installers in favour of eggs only. And you cannot (to my
> knowledge) convert an egg into a bdist_wininst installer, and if you
> can't compile from source (a C extension with complex dependencies,
> for example) you're stuck (in the sense that you're forced to use eggs
> without add/remove programs support).

You might want to look at the eGenix pre-built packages as an
alternative: they include all the information necessary to let
standard distutils continue its works *after* the build step.

It's basically a distribution of the package as it looks after
the build step has run, but before the package is wrapped up
using a packager like bdist_wininst or bdist_msi or installed
into the system.

You can download the pre-built package and create e.g. an
MSI installer or a wininst EXE without needing a compiler -
in addition to providing all the options of the standard distutils
"install" command (which makes repackaging them as part of
larger applications easy as well).

All the logic for this is included in mxSetup.py which ships with
the pre-built packages.

http://www.egenix.com/products/python/mxBase/#Download
http://www.egenix.com/products/python/mxBase/#Installation

The current version we have is not yet perfect. The next
iteration will also play nice with distutils extensions.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 20 2008)
 >>> Python/Zope Consulting and Support ...http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
___
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-archive.com

[Python-Dev] Proposal: from __future__ import unicode_string_literals

[Eric Smith]

Following up on a python-3000 discussion about making porting from 2.6 
to 3.0 easier.  Martin suggested making this its own thread.

This proposal is to add "from __future__ import 
unicode_string_literals", which would make all string literals in the 
importing module into unicode objects in 2.6.

This is similar to the -U flag, but would only affect a single module at 
a time.  I think history has shown that -U isn't really usable when 
using any number of modules, including many in the standard library.

There was another proposal from Christian Heimes to add "from __future__ 
import py3k_literals", which would:
1) '' creates an unicode object instead of a str object
2) b'' creates a str object (aka bytes in Python 3.0)
3) 1 creates a long instead of an int
4) 1L and u'' are invalid

2) is already taken care of in 2.6, since: type(b'') == str.  I don't 
think 3) is necessary.  It's an implementation detail.  4) is really two 
issues.  It's my understanding that there's a 2to3 fixer for both of 
these issues.  But I'm open to debate on this.

I'm willing to implement this if there's consensus on it.

Eric.
___
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-archive.com

[Python-Dev] Wow, I think I actually *get* it now!

[Phillip J. Eby]

At 10:08 PM 3/20/2008 +, [EMAIL PROTECTED] wrote (off-list):
>No, but in no situation, except one (where I was extremely pressed 
>for time) was I actually attempting to use setuptools to use any of 
>its features.  My experience of it is: "If a project uses distutils 
>or apt, installation probably works.  If it uses setuptools, it 
>probably throws a traceback or a wall of text explaining why my 
>environment is inadequate to perform the installation."  Other 
>people chose to use it and in so doing broke my setup.  Manually 
>copying a few files in these cases was a _lot_ easier than 
>attempting to diagnose and repair software that I didn't even want to use.
>
>I am not interesting in packaging or distribution.  Far from it: I 
>run all of my software out of an SVN checkout and I _detest_ being 
>involved in discussions of deployment or installation.
...
>However, the general message of the negative subjective experience I 
>have had while using setuptools is not FUD.  It's an accurate 
>portrayal of a great deal of frustration.  setuptools has, to this 
>date, not solved a single problem for *me*, personally or 
>professionally, but it has caused many.  distutils, despite its many 
>flaws, has actually solved quite a few.

Actually, this information is VERY helpful.  It makes it blindingly 
obvious to me now that the difference between loving and hating 
setuptools is whether you're *intentionally* using it, or whether it 
shows up in your ecosystem uninvited.  It also makes the difference 
in whether you get involved: with no investment in the tool itself, 
you have minimal motivation to RTFM, ask questions, or fix bugs.  And 
when people in this scenario *do* communicate to me or the 
distutils-sig, they are much more likely to be impatient and hostile, 
and more likely to view the system as "fundamentally broken".

This makes total sense to me now.  I don't have any *solutions* to 
the problem, mind you, but at least now I understand what before 
seemed like some sort of bizarre anomaly where literally thousands of 
people use setuptools and many dozens actually express their 
happiness with or even love for the system, and then others hate it 
like they hate Microsoft, or worse.  ;-)

Meanwhile, from the "outsiders" point of view, setuptools looks like 
the Matrix or the Borg, happily assimilating the masses, who then 
start coming to you and say, "But you'll be so much happier once you 
join us..."  ...and off in the distance, you hear a quiet rumbling of 
zombies chanting "ggs  s  mussst havve e!"  :)

Hm.  So it seems to me that maybe one thing that would help is a 
"Setuptools Haters' Guide To Setuptools" -- that is, *short* 
documentation specifically written for people who don't want to use 
setuptools and want to minimize its impact on their systems.  I could 
probably write something like that fairly easily, now that I have 
some idea of what to go in it, more than, "the existing documentation 
sucks".  :)

Can I count on some non-assimilated persons' help in critiquing such 
a document and suggesting any topics I miss?

___
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-archive.com

Re: [Python-Dev] svnmerge and added files

[Mike Klaas]

On 20-Mar-08, at 2:32 PM, Christian Heimes wrote:

> Martin v. Löwis schrieb:
>> It seems that recently, a number of merges broke in the sense
>> that files added to the trunk were not merged into the
>> 3k branch.
>>
>> Is that a general problem with svnmerge? Should that be
>> fixed to automatically do a "svn add" when merging changes
>> that included file additions and removals?
>
> It sometimes happens when I do a svnmerge, revert the merge with svn
> revert -R and do a second svnmerge. Files added by the first svnmerge
> aren't added to the commit list for the second merge. Unfortunately
> svnmerge.py doesn't warn me when the file already exists.

It may not warn explicitly about that, but it certainly does warn:

M ...
Skipped path/to/missing/file...
M ...
M ...

As someone who deals with svnmerge.py a lot, I find that it is  
appropriate to treat "Skipped" as critical as a conflict.

I too wish that it was more explicit in this respect.
-Mike
___
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-archive.com

Re: [Python-Dev] The Breaking of distutils and PyPI for Python 3000?

[skip]

>> I don't think any of the core committers is qualified to write such a
>> document. Instead, it would have to be written by people who
>> *actually* ported a project from 2 to 3 in some form.

Stephen> Note that this is precisely the kind of experience Skip
Stephen> Montanaro is talking about trying to generate in the context of
Stephen> SpamBayes ...

Correctamundo.  Give that man a cigar.

Skip
___
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-archive.com

Re: [Python-Dev] Wow, I think I actually *get* it now!

[Paul Moore]

On 20/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>  Actually, this information is VERY helpful.  It makes it blindingly
>  obvious to me now that the difference between loving and hating
>  setuptools is whether you're *intentionally* using it, or whether it
>  shows up in your ecosystem uninvited.

Exactly. I never thought to express that, but it precisely explains my
situation as well.

>  Hm.  So it seems to me that maybe one thing that would help is a
>  "Setuptools Haters' Guide To Setuptools" -- that is, *short*
>  documentation specifically written for people who don't want to use
>  setuptools and want to minimize its impact on their systems.  I could
>  probably write something like that fairly easily, now that I have
>  some idea of what to go in it, more than, "the existing documentation
>  sucks".  :)
>
>  Can I count on some non-assimilated persons' help in critiquing such
>  a document and suggesting any topics I miss?

I would do so. (From a Windows user's perspective).

Paul.
___
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-archive.com

Re: [Python-Dev] The Breaking of distutils and PyPI for Python 3000?

[Terry Reedy]

""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| This is probably not correct. However, in 2.6, you could write
| that as
|
| if type(s) is bytes: s = unicode(s, 'utf-8')
|
| as bytes is str in 2.6. If you want to support even older
| versions, do
|
| try:
|bytes
| except NameError:
|bytes = str
|
| somewhere, then write the code as I proposed above.

This is exactly the sort of thing that should be and I expect will be in 
the conversion docs. 



___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Greg Ewing]

At 12:58 AM 3/20/2008 -0400, Tres Seaver wrote:

> A lot of setuptools warts are driven by related design problems in the
> distutils, such as the choice to use imperative / procedural code for
> everything

If a distutils replacement is ever written, I'd like to
see it structured as a dependency graph, like a makefile,
with each node in the graph knowing how to transform its
inputs into its outputs.

That would make it a lot easier to extend to accommodate
new things like Pyrex. You'd just have to write a new
node class that knows how to turn .pyx files into .c
files, and the existing machinery would take it from
there.

-- 
Greg
___
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-archive.com

Re: [Python-Dev] Wow, I think I actually *get* it now!

[Robert Brewer]

Phillip J. Eby wrote:
> Hm.  So it seems to me that maybe one thing that would help is a
> "Setuptools Haters' Guide To Setuptools" -- that is, *short*
> documentation specifically written for people who don't want to use
> setuptools and want to minimize its impact on their systems.  I could
> probably write something like that fairly easily, now that I have
> some idea of what to go in it, more than, "the existing documentation
> sucks".  :)
> 
> Can I count on some non-assimilated persons' help in critiquing such
> a document and suggesting any topics I miss?

I'd be glad to help critique such a doc.


Robert Brewer
[EMAIL PROTECTED]

___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Robert Brewer]

Phillip J. Eby wrote:
> The other tool that would be handy to have, would be one that unpacks
> eggs into standard distutils-style installation.

Hear, hear. I'm an author of a couple libraries that need to
interoperate with others. Of the many eggs I've downloaded over the past
year, I'd say 80%+ are never installed or even built--I just want to
grep the source code, and using my preferred tools, not some lame Find
command in a ZIP browser menu.


Robert Brewer
[EMAIL PROTECTED]

___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Terry Reedy]

"Tres Seaver" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA1
|
| Paul Moore wrote:
|
| > 1. No integration with the system packager (Windows, in my case). If I
| > do easy_install nose, then nose does not show up in add/remove
| > programs. That significantly affects the way I manage my PC.
|
| Point taken. Of course, it isn't really a "program" at that point:  it
| is an installed "add-on" to Python.  However, if Windows users expect
| such add-ons to show up in the "system" list, that is good to know.

However, this Windows user, and I expect most, do NOT expect add-ons 
(things under the /Pythonx.y tree) to show up in the add/remove list. 
Please do not do that.  On my system, it already takes several seconds to 
'populate the list'.  It is bad enough that Windows Update occasionally 
adds entries like 'Windows Update KB284798324' instead of adding something 
to the separate 'Manage Windows components' subsystem with readable names 
and explanations.

The standard (and to me, preferable)  way of dealing with such things is to 
have an 'installation manager' that can reinstall as well as delete and 
that has a check box for various things to delete.  This is what Python 
needs.

Terry Jan Reedy



___
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-archive.com

Re: [Python-Dev] [Distutils] PEP 365 (Adding thepkg_resources module)

[Terry Reedy]

"Jeff Rush" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

| In your scenario, what happens when one egg pulls in another and another,
| until you have a hundred entries in your add/remove menu?

As I said in another response, I don't think such things belong in 
add/remove.



___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[zooko]

On Mar 20, 2008, at 7:44 AM, Tres Seaver wrote:

> Paul Moore wrote:

>> 4. Hard to use with limited connectivity. At work, I *only* have
>> access to the internet via Internet Explorer (MS based proxy). There
>> are workarounds, but ultimately "download an installer, then run it"
>> is a far simpler approach for me.
>
> I don't know how to make this requirement compatible with using shared
> dependencies,

We've done something like this.

The http://allmydata.org project bundles its easy_installable  
dependencies.  If you get the current trunk from our darcs repository  
[1], or get a release tarball or a snapshot tarball from [2], then it  
comes with a directory named "misc/dependencies" which has the source  
tarballs of our easy_installable dependencies.  You can browse this  
directory on the web: [3].

Therefore, if you manually satisfy the non-easy_installable  
dependencies, you can download an allmydata.org tarball, disconnect  
from the Internet (which we call "moving to a Desert Island"), and  
install it.

This is, as you say, "compatible with using shared dependencies"  
because setuptools will detect if you already have sufficiently new  
versions of some of these dependencies installed (for example, if  
they are installed in Debian packages), and then skip the step of  
installing that dependency from its source tarball.

The remaining dependencies that cannot be satisfied automatically by  
our setup.py are listed in the install.html [4].  They are:

1.  g++ >= v3.3 -- the Cygwin version of gcc/g++ works for Cygwin  
and for Windows
2. GNU make
3. Python >= v2.4.2 including development headers i.e. "Python.h"
4. Twisted >= v2.4.0 -- from the Twisted "sumo" source tarball
5. OpenSSL >= v0.9.7, including development headers
6. PyOpenSSL == v0.6
7. Crypto++ >= v5.2.1, including development headers

I am hoping that in the future Twisted (see twisted #1286 [5]) and  
pyOpenSSL will be easy_installable, and that our use of setuptools  
plugins will eventually replace our GNUmakefile and thus remove our  
dependency on GNUmake.  That will leave only g++, Python, OpenSSL,  
and Crypto++ as dependencies that a user has to manually deal with in  
order to build allmydata.org from source.

Regards,

Zooko

[1] http://allmydata.org/source/tahoe/trunk/
[2] http://allmydata.org/source/tahoe/tarballs/
[3] http://allmydata.org/trac/tahoe/browser/misc/dependencies
[4] http://allmydata.org/source/tahoe/trunk/docs/install.html
[5] http://twistedmatrix.com/trac/ticket/1286
___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Janzert]

Guido van Rossum wrote:
> On Wed, Mar 19, 2008 at 12:54 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> [a long message]
> 
> I'm back at Google and *really* busy for another week or so, so I'll
> have to postpone the rest of this discussion for a while. If other
> people want to chime in please do so; if this is just a dialog between
> Phillip and me I might incorrectly assume that nobody besides Phillip
> really cares.
> 

Since there seems to be a fair number of negative responses to 
setuptools, I just wanted to add a bit of positive counterbalance. I'm 
just a random python user that happens to track python-dev a bit, so 
take all this with the realization that I probably shouldn't have much 
input into anything. ;)

I've been using python for somewhere around 10 years to write various 
random small scripts, gui applications and recently web applications. 
For me setuptools is the best thing to happen to python since I've been 
using it. I develop and deploy on a seemingly constantly changing mix of 
various flavors of windows and linux. Unlike for others, I love that 
once I get setuptools installed I can just use the same commands to get 
the things I need. I guess the contrast for me is that python is the 
common base that I tend to work from not the underlying OS.

So I don't know if I'm part of a large number of quiet users or just 
happen to be an odd case that works really well with setuptools. I was 
disappointed when setuptools didn't make it into 2.5 and I really hope 
it or something very much like it can make it into a release in the near 
future. Because while setuptools certainly isn't perfect, for me at 
least, it is much, much better than nothing at all.

Brian Haskin

___
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-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Robert Brewer]

Janzert wrote:
> Since there seems to be a fair number of negative responses to
> setuptools, I just wanted to add a bit of positive counterbalance. I'm
> just a random python user that happens to track python-dev a bit, so
> take all this with the realization that I probably shouldn't have much
> input into anything. ;)
> 
> I've been using python for somewhere around 10 years to write various
> random small scripts, gui applications and recently web applications.
> For me setuptools is the best thing to happen to python since I've
been
> using it. I develop and deploy on a seemingly constantly changing mix
> of
> various flavors of windows and linux. Unlike for others, I love that
> once I get setuptools installed I can just use the same commands to
get
> the things I need. I guess the contrast for me is that python is the
> common base that I tend to work from not the underlying OS.
> 
> So I don't know if I'm part of a large number of quiet users or just
> happen to be an odd case that works really well with setuptools. I was
> disappointed when setuptools didn't make it into 2.5 and I really hope
> it or something very much like it can make it into a release in the
> near future. Because while setuptools certainly isn't perfect, for me
> at least, it is much, much better than nothing at all.

My interpretation of this is that setuptools suffers from the same
malaise all flexible apps do (but especially CLI apps it seems):
frequent users love the power and high volume of options, infrequent
users despise it. If you're installing apps all day, you probably use it
a lot more often than library devs like me who use it once every other
month (if we're forced to).


Robert Brewer
[EMAIL PROTECTED]

___
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-archive.com

Re: [Python-Dev] Not backporting PEP 3115 (metaclass __prepare__)

[Guido van Rossum]

On Tue, Mar 18, 2008 at 10:14 PM, Jack Diederich <[EMAIL PROTECTED]> wrote:
> We can't backport the __prepare__ syntax without requiring metaclass
>  definition on the 'class' line.  Because the __metaclass__ definition
>  can be at the end of the class in 2.6 we can't find it until after we
>  execute the class and that is too late to use a custom dictionary.

That's fine. We need some carrots to encourage people to upgrade too. :-)

>  I wish I had thought of that yesterday,

Me too...

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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-archive.com