Re: [Python-Dev] fixing tests on windows

[Trent Nelson]

> -Original Message-
> From: Tim Golden [mailto:[EMAIL PROTECTED]
> Sent: 04 April 2008 09:30
> To: Trent Nelson
> Cc: Python-Dev
> Subject: Re: [Python-Dev] fixing tests on windows

> Yes. I'm trying desperately hard to stick to a narrow remit
> of getting tests to run consistently in the face of messy
> file-locking semantics under Windows. I really don't want to
> wade into the minor minefield of making all the tests run
> with consistent temp file semantics. But I may have to.

Hey Tim, any progress on this?  I'd like to start working on this towards the 
weekend...

Trent.
___
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] how to easily consume just the parts of eggs that are good for you

[Phillip J. Eby]

At 10:00 AM 4/9/2008 +0200, Gael Varoquaux wrote:
>On Wed, Apr 09, 2008 at 12:41:32AM -0400, Phillip J. Eby wrote:
> > >The way to achieve a database for Python would be to provide tools for
> > >conversion of eggs to rpms and debs,
>
> > Such tools already exist, although the conversion takes place from
> > source distributions rather than egg distributions.
>
>What is the status of the deb backend? The only one I know is unofficial
>maintained by Andrew Straw, but my information my be lagging behind.

I was under the impression that there were 2 .deb tools, neither one 
"official" in any sense, any more than 'bdist_rpm' is really 
"official" for RPM-based systems.


>By the way, if these tools work well, they are priceless!

I haven't had need to use any of them, so I don't really know.

___
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] fixing tests on windows

[Tim Golden]

Trent Nelson wrote:
> 
>> -Original Message-
>> From: Tim Golden [mailto:[EMAIL PROTECTED]
>> Sent: 04 April 2008 09:30
>> To: Trent Nelson
>> Cc: Python-Dev
>> Subject: Re: [Python-Dev] fixing tests on windows
> 
>> Yes. I'm trying desperately hard to stick to a narrow remit
>> of getting tests to run consistently in the face of messy
>> file-locking semantics under Windows. I really don't want to
>> wade into the minor minefield of making all the tests run
>> with consistent temp file semantics. But I may have to.
> 
> Hey Tim, any progress on this?  I'd like to start working on this towards the 
> weekend...

Thanks for the prod, Trent. In short, yes, I spent some time on
this over the weekend but haven't had time since. I found myself 
becoming more and more worried at the amount I had to change, 
especially given rumblings on the list concerning not changing 
the tests if possible.

The possibilities I've been pursuing are these:

1) Leave TESTFN as-is and make the .unlink more robust

2) Leave TESTFN static but instead of "./@TEST" use the
tempfile module to generate a random name in whatever
temp dir applies for the test system. And make the .unlink
more robust.

3) Drop TESTFN and have a function testfn () which generates
a new tempdir filename every time. And make the .unlink more
robust.

Each of these approaches has had its problems, and I'm additionally
hampered by the fact that I don't run *nix or OSX (or any other
platform). I spent far more time than I really had setting up
a VMWare player with Ubuntu but I haven't got it to the point
of building the tests which won't run under Windows.

Pros and cons:

1) Running with a fairly aggressive directory watcher, this doesn't
do enough to make the tests worth. Not worth it.

2) A bit better, especially since the betting is that most of the
suspect apps (local search engines etc.) won't index %TEMP%. But...
certain tests run into problems because they assume that the filename
of TESTFN has no escape-needy characters such as the backslash. Need
to update at least those tests.

3) [This is what I was trying over the weekend]. Loads of work and
quite intrusive. I'll try to get hold of my patch this evening and
mail it over to you. Part of the problem is working out where each
test is expecting TESTFN to be the same file each time and where
it doesn't care.

I was heartened to see that you'd gone ahead with the -- almost as
invasive -- socket test changes. If you'd like to take on what I've
got so far, or simply to adopt your own strategy, please feel free.

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

[Python-Dev] Next monthly sprint/bugfix day?

[Trent Nelson]

Hi,

Is there another online sprint/bugfix day in the pipeline?  If not, can there 
be? ;-)

Trent.
___
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] fixing tests on windows

[Trent Nelson]

> Thanks for the prod, Trent. In short, yes, I spent some time
> on this over the weekend but haven't had time since. I found
> myself becoming more and more worried at the amount I had to
> change, especially given rumblings on the list concerning not
> changing the tests if possible.

> I was heartened to see that you'd gone ahead with the --
> almost as invasive -- socket test changes. If you'd like to
> take on what I've got so far, or simply to adopt your own
> strategy, please feel free.

I don't hold any weight to rumblings regarding "not changing the tests if 
possible".  The tests need to change.  They were never written with the intent 
to run in parallel without any resource contention.  That's an important goal, 
now.  Please send over any patches you've got, everything will be useful!  Now 
that the dust has (sort of) settled on the network-oriented tests, I'm ready to 
start attacking the I/O ones.

Trent.
___
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] unittest's redundant assertions: assertsvs. failIf/Unlesses

[Guido van Rossum]

On Tue, Apr 8, 2008 at 9:56 PM, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Apr 8, 2008, at 11:47 PM, Terry Reedy wrote:
>  > I think, however, that the docs should be revised now, for 2.6/3.0.
>  > In the list of methods under TestCase Objects, the preferred method
>  > of each
>  > pair (or triplit) should be given first and the others marked as
>  > future
>  > deprecations, not recommended for new test code.

>  +1 !
>
>  This kind of information, once known, should be included in all
>  maintained versions of the documentation so that users can build good
>  coding habits, or have more time to adjust existing code.

Great point, Fred! This sounds like a general strategy that we might
employ more often -- when deprecating something, the first step ought
to be to document the best practice.

-- 
--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] how to easily consume just the parts of eggs that are good for you

[Andrew McNabb]

On Wed, Apr 09, 2008 at 11:37:07AM +1000, Ben Finney wrote:
> 
> Moreover, many of us already have a database of *all* packages on the
> system, not just Python-language ones: the package database of our
> operating system. Adding another, parallel, database which needs
> separate maintenance, and only applies to Python packages, is not a
> step forward in such a situation.

I agree with you completely.  There are three things I can see myself
wanting from an easy_install command:

1) To download and install an RPM/dpkg to a system-wide location.  The
package is then removable using the normal system package manager.

2) To download the source of a package.

3) To install a package to my home directory.  I would much rather that
this hypothetical easy_install did `rpm --prefix "$HOME/.local" -ivh
some_package.rpm` than have a Python-specific database.

> > They both agreed that it made perfect sense. I told one of them
> > about the alternate proposal to define a new database file to
> > contain a list of installed packages, and he sighed and rolled his
> > eyes and said "So they are planning to reinvent apt!".
> 
> That's pretty much my reaction, too.

Me, too.

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


pgpNRz0ZLDRLL.pgp
Description: 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] [Distutils] how to easily consume just the parts of eggs that are good for you

[Paul Moore]

On 09/04/2008, Stanley A. Klein <[EMAIL PROTECTED]> wrote:
> IMHO, the main system without a package manager is Windows.  A reasonable
>  way to deal with Windows would be to create a package manager for it that
>  could be used by Python and anyone else who wanted to use it.  The package
>  manager could establish a file hierarchy similar to the Unix FHS and
>  install files appropriately, except for what is needed to satisfy the
>  Windows OS.  That would probably go a long way to addressing the issues
>  being discussed here.  This is primarily a Windows problem, not a Python
>  problem.

Windows does have a package manager - the add/remove programs
application. It's extremely limited, and doesn't make any attempt at
doing dependency resolution, certainly - but that's a separate issue.

I don't know if you use Windows (as in, develop programs using Python
on Windows). If you do, then I'd be interested in your views on
bdist_wininst and bdist_msi installers, and how they fit into the
setuptools/egg environment, particularly with regard to the package
manager you are proposing. If you don't use Windows, then I don't see
how you can usefully comment.

Personally, as I've said before, I don't have a problem with a
Python-only package manager, as long as it replaces or integrates
bdist_wininst and bdist_msi. Having two package managers is far worse
than having none - and claiming that add/remove programs "isn't a
package manager" is just ignoring reality (if it isn't, then why do
bdist_wininst and bdist_msi exist?).

Are the Linux users happy with having a Python package manager that
ignores RPM/apt? Why should Windows users be any happier?

Sorry - I'm feeling a little grumpy. I've read one too many "Windows
is so broken that people who use it obviously don't care about doing
things right" postings this week :-(

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] [Distutils] how to easily consume just the parts of eggs that are good for you

[zooko]

On Apr 8, 2008, at 9:41 PM, Phillip J. Eby wrote:
>
> I'm curious.  Have any of you actually read PEP 262 in any detail?

I read it, though not in fine detail.

I didn't write that you are planning to reinvent apt.  I wrote that  
when programmers hear about this PEP they exclaim "They are planning  
to reinvent apt!".

That is a matter of perception and marketing -- the value that I want  
to gain from Python packages is the value of a critical mass of good  
programmers using compatible tools for code re-use.  If a lot of  
programmers hate an idea, then it doesn't matter what the details are  
-- it isn't going to provide this value to me.

I think part of our disagreement is that we are talking about two  
overlapping use cases: programmer and sysadmin (and "end user" which  
is much like sysadmin).  I am not, at this time, interested in the  
sysadmin use case.  As I've mentioned, my sysadmin needs are  
currently well satisfied by apt (and sometimes by GNU stow), and my  
fellow sysadmins with whom I work are absolutely not going to relax  
their "apt-only policy" for the forseeable future, so I cannot use  
such a tool unless it is named "apt" and written by Debian/Ubuntu.

On the other hand I am very interested in the programmer use case,  
because setuptools/easy_install already works pretty well for that,  
and we are already very close to achieving a critical mass of good  
programmers.  Recently several more packages that my project [1]  
relies on have become easy_installable -- Twisted, pywin32 (thanks to  
you, PJE), and foolscap -- and several more have had bugfixes which  
make them work better with easy_install/setuptools -- Nevow and  
zope.interface -- and there are some patches in the queue to make  
another one compatible with setuptools -- pyflakes [2, 3].

So setuptools/easy_install is already (slowly) winning.  I want to  
accelerate that process by reducing the degree to which it is  
incompatible, inconvenient, or objectionable to other programmers.

PEP 262 sounds like a non-starter to me because

1.  It appears to be backwards-incompatible with setuptools/ 
easy_install/eggs, thus losing all the recently gained cooperation  
that I mentioned in the previous paragraph, and

2.  It defines a new database file, where I would prefer either:
a.  Doing away with database files entirely and relying on the  
filesystem alone to hold that information, or
b.  Continuing to use the current ".pth" database file format,  
possibly improved by having native support for .pth files in the  
Python import machinery.

3.  Because of #2, it triggers programmers to exclaim "They are  
planning to reinvent apt!", thus making it unlikely that the new  
proposal will recapture the cooperation that setuptools has already  
(slowly) gained.

I'm sorry, PJE -- I know it must be frustrating to you to have your  
proposal criticized on social rather than technical grounds -- but  
social benefits are what I am seeking right now.

Perhaps PEP 262 and my proposal are not actually alternatives, but  
are complementary.  I do not object to Python maintaining a database  
of installed packages for itself (although I cannot *rely* upon such  
behavior, not least because I will be maintaining backwards  
compatibility with Python 2.4 for at least the next several years,  
and with Python 2.5 for at least the next several years after that).  
What I want is for the already implemented, tested, and deployed code- 
re-use features of setuptools/easy_install to be more widely  
accepted.  This is best and most easily achieved by fixing the two  
most frequent objections to setuptools/easy_install: 1.  That you  
can't conveniently install into an arbitrary directory, and 2. that  
it subverts the meaning of your PYTHONPATH.

Regards,

Zooko

[1] http://allmydata.org/source/tahoe/trunk/docs/install.html
[2] http://divmod.org/trac/ticket/2535
[3] http://divmod.org/trac/ticket/2048
___
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] how to easily consume just the parts of eggs that are good for you

[Phillip J. Eby]

At 11:52 AM 4/9/2008 -0400, Stanley A. Klein wrote:
>However, are you implying that the installation information for Python egg
>packages accesses and coordinates with the rpm database?

Yes, when the information isn't stripped out.  Try a more recent Fedora.


>IMHO, the main system without a package manager is Windows.

You're ignoring shared environments and development 
environments.  (Not to mention Mac OS.)


>   A reasonable
>way to deal with Windows would be to create a package manager for it that
>could be used by Python and anyone else who wanted to use it.

Let us know when you've finished it, along with the one for Mac OS.  :)

Of course this still won't do anything for shared environments and 
development environments.


>You are talking here about bdist_rpm and not about a tool that would take
>a Python package distributed as an egg file and convert the egg to an rpm
>or a deb.  Unfortunately, some Python packagers are beginning to limit
>their focus only to egg distribution.  That creates a problem for users
>who have native operating system package management.

That is indeed a problem -- but it's a social one, not a technical 
one.  It's trivial for the publisher of an egg to change their 
command line from "setup.py bdist_egg upload" to "setup.py sdist 
bdist_egg upload", as soon as their users (politely) request that they do so.


> > Applying LSB and FHS to the innards of Python packages makes as much
> > sense as applying them to the contents of Java .jar files -- i.e.,
> > none.  If it's unchanging data that's part of a program or library,
> > then it's a program or library, just like static data declared in a C
> > program or library.  Whether the file extension is .py, .so, or even
> > .png is irrelevant.
>
>The FHS defines places to put specific kinds of files, such as command
>scripts (/bin, /usr/bin, /sbin, or /usr/sbin), documentation
>(/usr/share/doc/package-name), and configuration files (/etc).  There are
>several kinds of files identified and places defined to put them.
>Distribution by eggs has a tendency to scoop up all of those files and put
>them in /usr/lib/python/site-packages, regardless of where they belong.

Eggs don't include documentation or configuration files, and they 
install scripts in script directories, so I don't get what you're 
talking about here.  For any other data that a package accesses at 
runtime, my earlier comments apply.


>Having eggs support conformance to FHS would mean recognizing and tagging
>the relevant files.  A tool for converting eggs to rpms or debs would
>essentially reformat the egg to rpm or deb and put files where they
>belong.

No, because such files as you describe don't exist.  If you think 
they do, then either you have misunderstood the nature of the files 
in question, or the developer has incorrectly placed non-runtime 
files in their installation tree.

___
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] how to easily consume just the parts of eggs that are good for you

[Phillip J. Eby]

At 10:30 AM 4/9/2008 -0700, zooko wrote:
>PEP 262 sounds like a non-starter to me because
>
>1.  It appears to be backwards-incompatible with setuptools/ 
>easy_install/eggs, thus losing all the recently gained cooperation
>that I mentioned in the previous paragraph, and

No.  It provides a forward-compatibility path for the distutils, so 
that easy_install doesn't have to install things in .egg format in 
the future.  There's no compatibility breakage at all.


>2.  It defines a new database file,

No, it defines *files*.  One file per installed distribution, 
containing (among other things) an installation manifest.


>where I would prefer either:
>a.  Doing away with database files entirely and relying on the
>filesystem alone to hold that information, or

...which is what PEP 262 *does*.

Unfortunately, PEP 262's title is bad for marketing, as you've 
effectively pointed out.  It would be better titled something 
"package installation manifests" or "package contents files", or 
something of that sort.

>b.  Continuing to use the current ".pth" database file format,
>possibly improved by having native support for .pth files in the
>Python import machinery.

These mechanisms are orthogonal to this issue.


>3.  Because of #2, it triggers programmers to exclaim "They are
>planning to reinvent apt!", thus making it unlikely that the new
>proposal will recapture the cooperation that setuptools has already
>(slowly) gained.

Yeah, we need a new name.  Everybody is going off of "database of 
installed packages" and thinking "apt", because they aren't paying 
any closer attention.  However, given that we are discussing this on 
Python-Dev and distutils-sig, I do think it's reasonable to expect 
(if perhaps not reasonable to receive) that people discussing the PEP 
have *read* the freaking PEP first, prior to trashing it or offering 
alternatives.

And it's not like I'm personally offended or anything -- I didn't 
even write the PEP in question.  But what's the point of having PEPs 
if people read nothing but their titles?  We could just delete 
everything but PEP 0.  :)


>Perhaps PEP 262 and my proposal are not actually alternatives, but
>are complementary.

As I've already pointed out, your proposal does not address multiple 
installed versions of a package, and I see no sane way to modify it to do so.


>What I want is for the already implemented, tested, and deployed 
>code- re-use features of setuptools/easy_install to be more widely
>accepted.  This is best and most easily achieved by fixing the two
>most frequent objections to setuptools/easy_install: 1.  That you
>can't conveniently install into an arbitrary directory, and 2. that
>it subverts the meaning of your PYTHONPATH.

As I've already stated, the only way for these problems to be fixed 
is for easy_install to not install files in .egg form -- which also 
solves the general objection to using .eggs in the first place.

And the only way to do that, is to have a way to keep track of what 
files are installed.  Rather than have easy_install come up with its 
own way of doing that, I would prefer to share a standard with the 
distutils.  Hence, the PEP discussion.

For earlier versions of Python, it will still be possible to install 
and uninstall with setuptools using this approach.  You just won't be 
able to uninstall pure distutils-based packages, unless you installed 
them using easy_install.

Meanwhile, it has occurred to me that the easiest way of handling 
compatibility is not to require that other packaging tools mark their 
files for non-removability, but simply not allow easy_install to 
remove or overwrite anything that *isn't* claimed by a manifest.  In 
that way, easy_install would be immediately usable in the new mode, 
without any updates to Python or to system packaging tools.

___
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] how to easily consume just the parts of eggs that are good for you

[zooko]

On Apr 8, 2008, at 4:36 PM, Greg Ewing wrote:
>
> I discovered another annoyance with eggs the other day -- it
> seems that tracebacks referring to egg-resident files contain the
> pathname of some temporary directory that existed when the egg
> was being packaged, rather than the one it actually exists in
> at run time.

Brian Warner and I discovered that issue yesterday, too.  We  
determined that if you install the egg (with easy_install or with a  
setuptools-powered ./setup.py install) in unzipped form then the  
source file names get rewritten so that your stack traces come with  
source lines.

If you have a package which requires stack traces to come with source  
lines, then you could pass "zip_safe=False" to the call to setup().

I would prefer that zip_safe=False were the default and that either  
the producer or the consumer of a package had to specifically choose  
zip_safe=True in order to install eggs in zipped form.

I've opened a ticket on my setuptools trac:

http://allmydata.org/trac/setuptools/ticket/4

Regards,

Zooko

___
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] how to easily consume just the parts of eggs that are good for you

[Phillip J. Eby]

At 12:30 PM 4/9/2008 -0700, zooko wrote:

>On Apr 8, 2008, at 4:36 PM, Greg Ewing wrote:
> >
> > I discovered another annoyance with eggs the other day -- it
> > seems that tracebacks referring to egg-resident files contain the
> > pathname of some temporary directory that existed when the egg
> > was being packaged, rather than the one it actually exists in
> > at run time.
>
>Brian Warner and I discovered that issue yesterday, too.  We
>determined that if you install the egg (with easy_install or with a
>setuptools-powered ./setup.py install) in unzipped form then the
>source file names get rewritten so that your stack traces come with
>source lines.

Are you using Python 2.5?  As of 2.5, the linecache module should 
correctly read the source line from the present location of the 
source file the module was loaded from, regardless of the file name 
specified in the traceback.


>If you have a package which requires stack traces to come with source
>lines, then you could pass "zip_safe=False" to the call to setup().
>
>I would prefer that zip_safe=False were the default and that either
>the producer or the consumer of a package had to specifically choose
>zip_safe=True in order to install eggs in zipped form.

A better fix would be for Python to use relative paths in 
co_filename, as this would fix similar problems that occur whenever 
you move .pyc/.pyo files around.

___
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] Compiling Python on a biarch (PPC/PPC64)

[Sérgio Durigan Júnior]

Hi everybody :-)

I'm running a PPC64 biarch here (i.e., a 64-bit kernel with 32-bit
userspace), and trying to compile Python on it. Well, as I have a GCC
compiler that generates natively 32-bit executables, everything goes
well when I *don't* use any specific 64-bit flag (./configure
--enable-shared && make && make test && make install).

My problem happens when I try to compile Python for PPC64 using some
configure flags and environment variables, like --target and CFLAGS. To
be more specific, that's what I tried:

./configure --enable-shared --target=powerpc64-unknown-linux
CFLAGS='-m64'

The configure runs fine. But when I do a "make":

[EMAIL PROTECTED] ~/work/w/Python-2.5.2 $ make
gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes  -I. -IInclude -I./Include  -fPIC -DPy_BUILD_CORE -o
Modules/python.o ./Modules/python.c
In file included from Include/Python.h:57,
 from ./Modules/python.c:3:
Include/pyport.h:761:2: error: #error "LONG_BIT definition appears wrong
for platform (bad gcc/glibc config?)."
make: *** [Modules/python.o] Error 1

Well, now starts the part where I try to understand things, so please
correct me if I'm wrong ;-). After some investigation, I thought that
the error was the (absence of) detection of the building target, so I
wrote a little piece of code in configure.in which detects PPC64 in the
$target variable and appends to $BASECFLAGS the string '-m64'. It seems
to be more than that, though (because that approach didn't work
completely)... Can anyone give me a hand on this? As far as I could
investigate, I must change setup.py in order to get this issue fixed,
right?

Thanks in advance,

-- 
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil

___
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] windows (was: how to easily consume just the parts of eggs that are good for you)

[Jim Jewett]

> Are the Linux users happy with having a Python
> package manager that ignores RPM/apt? Why
> should Windows users be any happier?

Because, as you noted, the add/remove programs application is severely
limited.

> I've read one too many "Windows is so broken
> that people who use it obviously don't care about
> doing things right" postings this week

I'm honestly not sure that such fine-grained control is the right user
interface, particularly for a non-shared system.

But even if it were, Windows doesn't really have it, and it isn't so
valuable that a solution which works only for python could do much
better than the existing 3rd-party setup tools.



As a windows user, I don't want python packages showing up in the
add/remove programs list, because it won't help me, and will make the
few times I do use that tool even more awkward.

That said, I agree that if python does package management, offering
windows users the choice of using that application is probably a good
idea.  The catch is that "package managers" seem to offer far more
fine-grained power (even without dependency resolution) than windows.
Duplicating this would add lots of complexity just for windows -- and
still might not be all that useful.  I'm already used to looking for
an uninstall.exe in the  directory of anything I can actually
uninstall, and accepting that most things just don't go away cleanly.
As a programmer, this feels wrong, but ... it is probably a good
tradeoff for the time I don't want to spend maintaining things.

If I really wanted a fancy tool that took care of dependencies and
alternate versions, I would be willing to run something
python-specific, or to treat each package as a subcomponent that I
managed through "Change an existing program" applied to python.

But realistically, I don't see such a tool being used often enough to
justify inclusion in the core.

-jJ
___
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] how to easily consume just the parts of eggs that are good for you

[Phillip J. Eby]

At 04:43 PM 4/9/2008 -0400, Stanley A. Klein wrote:
>I don't understand what you mean by "shared environments and development
>  environments".

I mean that in a shared or development environment, a system packager 
isn't useful, since it expects things to live in *one* place, and 
usually to have only one *version*, as well.


>I agree that we are dealing with a combination of technical and social
>issues here.  However, I think it takes a lot more understanding for a
>publisher to get everything straight.

If they provide you with the source distribution, you can make any 
sort of package you want.


> > Eggs don't include documentation or configuration files, and they
> > install scripts in script directories, so I don't get what you're
> > talking about here.  For any other data that a package accesses at
> > runtime, my earlier comments apply.
> >
>
>But rpms and debs do include these files, plus manual pages, localization
>files and a lot of other ancillary stuff.

...just one of the many reasons that eggs are not a replacement for 
rpms and debs.  :)


>Most of the Python tarballs I have downloaded have all kinds of files in
>their installation trees.  This is a major pain in the you-know-what for
>someone trying to use bdist_rpm and get proper, FHS-compliant rpms.  If
>eggs are supposed to be strictly runtime files, I think very few
>developers actually understand that.  Better yet, how do you define what
>should be included in an installation?  It sounds like the egg concept
>doesn't include several kinds of files that rpm and deb would include in
>an installation.  I think that may be an important issue here.

It would be, if .eggs were a packaging format, rather than a binary 
distribution/runtime format.

Remember "eggs are to Python as jars are to Java" -- a Java .jar 
doesn't contain documentation either, unless it's needed at 
runtime.  Same for configuration files.

They're not system packages, in other words.  The assumption that 
they are is another marketing failure, due to conflation of "package 
== distribution of python code" and "package == thing you manage with 
a system packager".  People see, "I put my package in an .egg" and 
think it's the latter definition, when it's barely even the former.  :)

___
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] Compiling Python on a biarch (PPC/PPC64)

[Martin v. Löwis]

> Can anyone give me a hand on this? As far as I could
> investigate, I must change setup.py in order to get this issue fixed,
> right?

Wrong. I didn't read your entire message, but this is definitely wrong.
setup.py isn't invoked until python itself is built, and
Modules/python.c is part of python itself.

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] how to easily consume just the parts of eggs that are good for you

[zooko]

On Apr 9, 2008, at 6:00 AM, Phillip J. Eby wrote:
>>
>> By the way, if these tools work well, they are priceless!
>
> I haven't had need to use any of them, so I don't really know.

They are easydeb [1] and stddeb [2].  The former appears to be  
incomplete and unmaintained.  The latter appears to be usable, but  
somewhat incomplete -- substantial manual labor is required to use it  
successfully, as documented by my programming partner Brian Warner in  
this ticket: [3].

Regards,

Zooko

[1] http://easy-deb.sourceforge.net/
[2] http://stdeb.python-hosting.com/
[3] http://allmydata.org/trac/tahoe/ticket/251
___
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] how to easily consume just the parts of eggs that are good for you

[zooko]

On Apr 9, 2008, at 12:40 PM, Phillip J. Eby wrote:
>>
>> You are talking here about bdist_rpm and not about a tool that  
>> would take
>> a Python package distributed as an egg file and convert the egg to  
>> an rpm
>> or a deb.  Unfortunately, some Python packagers are beginning to  
>> limit
>> their focus only to egg distribution.  That creates a problem for  
>> users
>> who have native operating system package management.
>
> That is indeed a problem -- but it's a social one, not a technical
> one.  It's trivial for the publisher of an egg to change their
> command line from "setup.py bdist_egg upload" to "setup.py sdist
> bdist_egg upload", as soon as their users (politely) request that  
> they do so.

In general, it would be good if eggs came with .py files by default  
instead of .pyc files.

I've opened a ticket on my setuptools trac about this proposal:

http://allmydata.org/trac/setuptools/ticket/5 # binary eggs should  
come with .py files by default, rather than .pyc files

Regards,

Zooko
___
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] how to easily consume just the parts of eggs that are good for you

[Paul Moore]

On 09/04/2008, Stanley A. Klein <[EMAIL PROTECTED]> wrote:
>  I think you raise an interesting issue:  What is a package manager?

My (very simplistic) answer is that it's whatever someone uses to
manage packages. What level of functionality it has is irrelevant, as
long as it suits an individual's way of working.

>  I don't think I ever said that Windows is broken in the area of package
>  management.

I hope I didn't say you had - but it is an often-raised point, and it
does grate on me (as by implication, it says that what I do isn't
"real" package management). It's just another flavour of the old
Windows vs Linux OS wars, which I don't want to participate in :-)

>  My own experience is that the files of Windows programs tend
>  to be put in a directory devoted to the program, rather than put in
>  directories with other files having similar purposes.  At one time, the
>  default location in Windows for word processing files was even in a
>  sub-directory of the word processing program.  That changed to having a
>  form of user home directory, but it didn't change much for the program
>  files themselves.  Unix/Linux puts the files in specific areas of the file
>  system having functional commonality.  One could almost say that the
>  Windows default approach to structuring its filesystem avoids or minimizes
>  the need for package management.

Agreed. The minimal package manager on Windows is arguably reasonable
precisely because the standard layout doesn't require much more.

On the other hand, Microsoft has a bad habit of changing their
"standards", and in particular Vista changes a lot of things. But
that's very off-topic, so I'll avoid going into detail here.

>  I repeat that this issue mainly arises because Windows doesn't have the
>  same kind of filesystem structure (and therefore the need for package
>  management) that other systems have.  I don't know what Windows add/remove
>  programs function does, but all it might do is to run the executable to
>  install packages and record the installation (as was previously done by
>  third party programs) to facilitate clean removal.

Precisely. I could argue that the Linix filesystem structure is over
complex, and causes the need for complex package managers, precisely
because it's impossible to manually keep track of what file is owned
by what package. But this way lies OS wars, so I won't make a major
point of this, but just ask that people consider it as a possibility.

(I believe that Mac OS X goes for an even simpler structure -
applications store *everything* in the one directory, so that
install/uninstall is simply a directory copy/remove. I won't comment
on what that proves...)

>  Unless you can perform
>  more of the other functions I listed above, I doubt I would call
>  add/remove a package manager.

OK. I would, though, as I don't really want much more.

Later, you said:

> I just don't do Windows.  :-)

And you've been pretty clear that you're looking for information
rather than trying to explain how you think Windows should work. But
many people aren't so balanced in their views, and that makes it hard
to have a discussion - I'd suggest that people without Windows
experience leave the Windows side to the Windows people, and accept
that when they say "XXX won't work for us", that the statement is
probably true.

I find this whole discussion hugely confusing, because a lot of people
are stating opinions about environments which it seems they don't use,
or know much about. I don't know how to avoid this, but it does make
it highly unlikely that any practical progress will get made.

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] [Distutils] how to easily consume just the parts of eggs that are good for you

[Paul Moore]

On 09/04/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> It would be, if .eggs were a packaging format, rather than a binary
>  distribution/runtime format.
>
>  Remember "eggs are to Python as jars are to Java" -- a Java .jar
>  doesn't contain documentation either, unless it's needed at
>  runtime.  Same for configuration files.

And yet, Java doesn't have an equivalent of easy_install for jar
files, to my knowledge. If Python had eggs but no easy_install, maybe
this whole discussion wouldn't be taking place.

(I know I personally like the idea of egg-as-jar-file, but *hate* the
idea of egg-as-dependency-handling-tool-and-everything-else).

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] how to easily consume just the parts of eggs that are good for you

[Ben Finney]

"Stanley A. Klein" <[EMAIL PROTECTED]> writes:

> IMHO, the main system without a package manager is Windows.

AFAICT the MacOS platform also lacks in this area.

> A reasonable way to deal with Windows would be to create a package
> manager for it that could be used by Python and anyone else who
> wanted to use it. [...] This is primarily a Windows problem, not a
> Python problem.

I'd rephrase this as: If you *must* re-invent package management for
those legacy systems without it, please *don't* make it specific to
Python.

-- 
 \  “The right to search for truth implies also a duty; one must |
  `\not conceal any part of what one has recognized to be true.” |
_o__)   —Albert Einstein |
Ben Finney

___
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] how to easily consume just the parts of eggs that are good for you

[Paul Moore]

On 09/04/2008, Ben Finney <[EMAIL PROTECTED]> wrote:
> "Stanley A. Klein" <[EMAIL PROTECTED]> writes:
>  > A reasonable way to deal with Windows would be to create a package
>  > manager for it that could be used by Python and anyone else who
> > wanted to use it. [...] This is primarily a Windows problem, not a
>  > Python problem.
>
>  I'd rephrase this as: If you *must* re-invent package management for
>  those legacy systems without it, please *don't* make it specific to
>  Python.

And I would say that Windows doesn't have a problem. Are any Windows
users proposing building a package management system for Windows
(Python-specific or otherwise)? It's a genuine question - is this
something that Windows users are after, or is it just Linux users
trying to show Windows users what they are missing?

(BTW, it's unreasonable to call Windows "legacy" - whatever that word
means, Windows ain't it (yet...))

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] [Distutils] how to easily consume just the parts of eggs that are good for you

[Phillip J. Eby]

At 03:20 PM 4/9/2008 -0700, zooko wrote:
>I've opened a ticket on my setuptools trac about this proposal:
>
>http://allmydata.org/trac/setuptools/ticket/5 # binary eggs should
>come with .py files by default, rather than .pyc files

Filling your tracker with already-rejected proposals isn't likely to 
encourage me to look at it, especially when I've personally rejected 
them to you in IRC.  That goes for your ticket #4 as well.

___
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] how to easily consume just the parts of eggs that are good for you

[Phillip J. Eby]

At 11:48 PM 4/9/2008 +0100, Paul Moore wrote:
>On 09/04/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > It would be, if .eggs were a packaging format, rather than a binary
> >  distribution/runtime format.
> >
> >  Remember "eggs are to Python as jars are to Java" -- a Java .jar
> >  doesn't contain documentation either, unless it's needed at
> >  runtime.  Same for configuration files.
>
>And yet, Java doesn't have an equivalent of easy_install for jar
>files, to my knowledge.

Actually, OSGi and Eclipse plugins and "feature sites" come quite 
close, and setuptools rips off many of its features from them.  OSGi 
is basically a standard for additional .jar metadata to encompass 
dependencies and other info.

___
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] how to easily consume just the parts of eggs that are good for you

[Dave Peterson]

Phillip J. Eby wrote:



Applying LSB and FHS to the innards of Python packages makes as much
sense as applying them to the contents of Java .jar files -- i.e.,
none.  If it's unchanging data that's part of a program or library,
then it's a program or library, just like static data declared in a C
program or library.  Whether the file extension is .py, .so, or even
.png is irrelevant.
  

The FHS defines places to put specific kinds of files, such as command
scripts (/bin, /usr/bin, /sbin, or /usr/sbin), documentation
(/usr/share/doc/package-name), and configuration files (/etc).  There are
several kinds of files identified and places defined to put them.
Distribution by eggs has a tendency to scoop up all of those files and put
them in /usr/lib/python/site-packages, regardless of where they belong.



Eggs don't include documentation or configuration files, and they 
install scripts in script directories, so I don't get what you're 
talking about here.  For any other data that a package accesses at 
runtime, my earlier comments apply.
  


We've talked a bit about this before, and IIRC, at that time you 
(Phillip) were willing to consider patches to setuptools that allowed 
for the inclusion of documentation in eggs such that it was placed into 
an LSB/FHS appropriate directory (or some standard dir for non-LSB 
systems) during the install process.   I'm assuming that something 
similar for config files wouldn't be a problem either?  Or is this whole 
idea out the window given the way the discussion has trended and the 
reiteration above that eggs are meant to be similar in principal to jars?  



Not that I have a patch yet, but we've been working on it in our "spare 
time" over here at Enthought.  I'm now wondering if we're wasting our 
time. :-)



I think the biggest use-case confusion in the current discussion is 
whether we're talking about applications or libraries?  If we're talking 
about libraries, then clearly distribution of only executables is 
sufficient because anything else should be handled by the application 
distribution when that library is used in an app.  Whereas if we're 
talking about applications, you probably *do* want to include 
documentation, configuration info, etc. in your distribution.   I think 
I can sum up any further points by simply asking: "Should it be safe to 
assume I can distribute my application via eggs / easy_install just 
because it is written in Python?"



-- Dave

___
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] how to easily consume just the parts of eggs that are good for you

[Phillip J. Eby]

At 12:51 AM 4/10/2008 +0200, Gael Varoquaux wrote:
>On Wed, Apr 09, 2008 at 11:46:19PM +0100, Paul Moore wrote:
> > I find this whole discussion hugely confusing, because a lot of people
> > are stating opinions about environments which it seems they don't use,
> > or know much about. I don't know how to avoid this, but it does make
> > it highly unlikely that any practical progress will get made.
>
>I find that something that doesn't help at all the discussion move
>forward is that everybody has different usecases in mind, on different
>platforms, and is not interested in other people's usecases.
>
>Hopefuly I am wrong,

You're not wrong at all.  I have to deal with *all* the platforms and 
use cases, which makes it quite frustrating when people who haven't 
even read the requirements are making proposals to "solve" things in 
ways that break for everyone except their own niche platform+usecase 
combination.

Guido, can I borrow the time machine and go back and NOT try to 
improve on the distutils?  Or is there already too much collateral 
damage to the timeline? ;-)

___
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] how to easily consume just the parts of eggs that are good for you

[Greg Ewing]

zooko wrote:
> 
> We  determined 
> that if you install the egg (with easy_install or with a  
> setuptools-powered ./setup.py install) in unzipped form then the  source 
> file names get rewritten so that your stack traces come with  source lines.

That wouldn't have helped me with my problem, because I was
trying to use the traceback to track down where the file was
in the first place. I wasn't even aware that it was in an
egg at first.

I wouldn't have been using eggs at all if I hadn't been
tricked into it by some package telling me I had to use
easy_install to install it. If I'd known that setuptools
would make intrusive changes to the behaviour of my
system, I would never have touched it.

Is there a way of *un*installing setuptools? I'd like to
put my Python back the way it used to be.

-- 
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] how to easily consume just the parts of eggs that are good for you

[Greg Ewing]

Phillip J. Eby wrote:
> Are you using Python 2.5?  As of 2.5, the linecache module should 
> correctly read the source line from the present location of the source 
> file the module was loaded from, regardless of the file name specified 
> in the traceback.

I think it was doing that, but I was trying to find the file,
and the traceback wasn't helping.

> A better fix would be for Python to use relative paths in co_filename, 
> as this would fix similar problems that occur whenever you move 
> .pyc/.pyo files around.

Yes, it must be possible to do something better. The actual path
is known when the module is loaded, so it should just be a matter
of storing it somewhere appropriate.

-- 
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] [Distutils] how to easily consume just the parts of eggs that are good for you

[zooko]

On Apr 9, 2008, at 4:12 PM, Phillip J. Eby wrote:

>> http://allmydata.org/trac/setuptools/ticket/5 # binary eggs should
>> come with .py files by default, rather than .pyc files
>
> Filling your tracker with already-rejected proposals isn't likely  
> to encourage me to look at it, especially when I've personally  
> rejected them to you in IRC.  That goes for your ticket #4 as well.

Part of my motivation in maintaining this tracker is to take issue  
discussions from IRC, and from mailing lists, and make them more  
permanent and structured.  This part is useful even for rejected  
proposals, as an historical record that other people interested in  
those issues can consult.

I will mark those two tickets as "rejected by PJE".  Could you please  
repeat (so that I don't misrepresent you due to my faulty memory of  
our IRC discussion from more than a year ago) your reason for  
rejecting these two:

http://allmydata.org/trac/setuptools/ticket/4 (when considering  
whether to zip, err on the side of safety rather than performance)

http://allmydata.org/trac/setuptools/ticket/5 (binary eggs should  
come with .py files by default, rather than .pyc files)

You are of course welcome to log in to that trac and update those  
tickets yourself, but if you prefer not to then I will paste your  
reasons into those tickets.

Regards,

Zooko
___
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] how to easily consume just the parts of eggs that are good for you

[Alexander Michael]

On Wed, Apr 9, 2008 at 3:40 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>  That is indeed a problem -- but it's a social one, not a technical
>  one.  It's trivial for the publisher of an egg to change their
>  command line from "setup.py bdist_egg upload" to "setup.py sdist
>  bdist_egg upload", as soon as their users (politely) request that they do so.

I know you say it in
,
but perhaps you should be more explicit about the best practice being
to distribute an sdist as well as one or more eggs and highlight this
with some standout text like:

"""
When uploading your project to PyPI, always upload your sdist in
addition to any eggs unless you have a good idiosyncratic reason not
to. The easy_install tool can also download and install sdist's on all
platforms (universally for pure-python packages and provided compilers
are available for distributions containing python extensions), so
uploading them gives your project the widest possible audience.
"""

Perhaps this will help some the social challenges.

Regards,
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] how to easily consume just the parts of eggs that are good for you

[Stephen J. Turnbull]

Ben Finney writes:
 > "Stanley A. Klein" <[EMAIL PROTECTED]> writes:
 > 
 > > IMHO, the main system without a package manager is Windows.
 > 
 > AFAICT the MacOS platform also lacks in this area.

Actually, they both have them.  Windows has Cygwin (rpm-based), while
for MacOS Fink (deb-based), MacPorts (FreeBSD ports-like), and
NetBSD's pkgsrc are all viable options if you want packaging support
for 3rd-party packages.

___
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] how to easily consume just the parts of eggs that are good for you

[Steven Bethard]

On Wed, Apr 9, 2008 at 4:48 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 09/04/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>  > It would be, if .eggs were a packaging format, rather than a binary
>  >  distribution/runtime format.
>  >
>  >  Remember "eggs are to Python as jars are to Java" -- a Java .jar
>  >  doesn't contain documentation either, unless it's needed at
>  >  runtime.  Same for configuration files.
>
>  And yet, Java doesn't have an equivalent of easy_install for jar
>  files, to my knowledge. If Python had eggs but no easy_install, maybe
>  this whole discussion wouldn't be taking place.
>
>  (I know I personally like the idea of egg-as-jar-file, but *hate* the
>  idea of egg-as-dependency-handling-tool-and-everything-else).

So then do you really need anything more than the 2.6 support for
executing directories (and zipfiles) with a __main__ file?

$ python_d.exe --version
Python 2.6a1+

$ more foo\__main__.py
print 'here I am!'

$ python_d.exe foo
here I am!
[8698 refs]

$ python_d.exe foo.zip
here I am!
[8563 refs]

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