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

Re: [Python-Dev] trunk buildbot status

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:

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

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 > ==

Re: [Python-Dev] trunk buildbot status

>> 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] >> >

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

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 ca

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

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 >k

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

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

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

> "... 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 t

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

> 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 maili

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

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 th

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

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-b

Re: [Python-Dev] trunk buildbot status

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 h

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

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

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

-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-di

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

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?

Re: [Python-Dev] Improved thread switching

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

Re: [Python-Dev] platform management

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 regist

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

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

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

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 "classif

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

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

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

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 ec

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

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

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

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 / .t

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

-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 イェルーン ラウフロック ヴァン デル ウェルヴェン h

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

-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

Re: [Python-Dev] Improved thread switching

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

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

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 tho

Re: [Python-Dev] Trove classifiers

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 lift

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

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? (A

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

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 pr

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

> 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 Unsu

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

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 > behavi

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

> 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 u

Re: [Python-Dev] platform management

> 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 tha

Re: [Python-Dev] Trove classifiers

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"

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

> 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

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

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 _

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

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

Re: [Python-Dev] Improved thread switching

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 pl

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

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 (do

Re: [Python-Dev] Improved thread switching

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 en

Re: [Python-Dev] Improved thread switching

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 >>

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

"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

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

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* wan

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

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

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

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

[Python-Dev] Python source code on Bazaar vcs

-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

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

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 pai

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

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

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

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

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

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 Un

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

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 i

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

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 > >

[Python-Dev] svnmerge and added files

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, Ma

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

-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 ver

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

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 con

Re: [Python-Dev] svnmerge and added files

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 fi

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

> 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 fo

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

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

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

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]:

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

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

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

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 n

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

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 significan

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

>> 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 replac

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

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

[Python-Dev] Proposal: from __future__ import unicode_string_literals

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.

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

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 pro

Re: [Python-Dev] svnmerge and added files

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 automatica

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

>> 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

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

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 un

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

""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: |by

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

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 g

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

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 > pro

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

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%+

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

"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 | > pro

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

"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.

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

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 simpl

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

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

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

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 >

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

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 > exe