At 08:45 AM 2/22/2009 -0800, Guido van Rossum wrote:
I've received some enthusiastic emails from someone who wants to
revive restricted mode. He started out with a bunch of patches to the
CPython runtime using ctypes, which he attached to an App Engine bug:
At 07:56 PM 2/22/2009 -0800, Guido van Rossum wrote:
On Sun, Feb 22, 2009 at 7:39 PM, P.J. Eby p...@telecommunity.com wrote:
Just a question, but, if you just need a pure-python restricted environment
for App Engine, why not just use the RestrictedPython package (i.e.,
http://pypi.python.org
At 03:52 PM 2/24/2009 +0100, Victor Stinner wrote:
Le Tuesday 24 February 2009 15:46:04 Andrew Dalke, vous avez écrit :
A goal is to use this in App Engine, yes? Which uses cgitb to report
errors? Which needs these restricted frame attributes to report the
values of variables when the error
At 10:41 AM 3/2/2009 +, Paul Moore wrote:
2009/3/2 Benjamin Peterson benja...@python.org:
2009/3/1 Paul Moore p.f.mo...@gmail.com:
Is it worth getting simplegeneric exposed in 3.1
(http://bugs.python.org/issue5135)? If it's going to be in 2.7, I'd
like to see it hit 3.1. The patch is
At 09:14 PM 3/2/2009 +, Paul Moore wrote:
2009/3/2 Jeffrey Yasskin jyass...@gmail.com:
I tend to think it's a bug in ABCs. You seem to have thought of
several possible ways to fix it, and I don't have strong preferences
between them.
I've discussed ways of fixing simplegeneric, but not
At 06:28 AM 3/16/2009 +1000, Nick Coghlan wrote:
There are some practical hurdles to that idea (specifically, creating a
callable which uses its parent's namespace rather than having its own),
but the basic concept seems sound.
Actually, that bit's pretty simple -- they're just nonlocal
At 04:45 PM 3/21/2009 +1000, Nick Coghlan wrote:
I really like the PEP - it's a solid extension of the ideas introduced
by PEP 342.
(Replying to you since I haven't seen any other thread on this)
My concern is that allowing 'return value' in generators is going to
be confusing, since it
At 10:21 AM 3/22/2009 +1200, Greg Ewing wrote:
P.J. Eby wrote:
My concern is that allowing 'return value' in generators is going
to be confusing, since it effectively causes the return value to
disappear if you're not using it in this special way with some
framework that takes advantage
At 08:11 PM 3/22/2009 +1200, Greg Ewing wrote:
P.J. Eby wrote:
(I'm thus finding it hard to believe there's a non-contrived
example that's not doing I/O, scheduling, or some other form of
co-operative multitasking.)
Have you seen my xml parser example?
http://www.cosc.canterbury.ac.nz
At 10:22 PM 3/24/2009 -0400, Steve Holden wrote:
There is one non-trivial extension that I've been chewing over for a
while. What if you want to yield not the values from the generator but
some function of those values? The present proposal appears to have no
way to specify that. What about
At 06:03 PM 3/25/2009 +1200, Greg Ewing wrote:
I wanted a way of writing suspendable functions that
can call each other easily. (You may remember I
originally wanted to call it call.) Then I noticed
that it would also happen to provide the functionality
of earlier yield from suggestions, so I
At 12:25 PM 3/25/2009 +, Antoine Pitrou wrote:
Paul Moore p.f.moore at gmail.com writes:
3. Setuptools, unfortunately, has divided the Python distribution
community quite badly.
Wait a little bit, and it's gonna be even worse, now that buildout
and pip seem
to become popular. For
At 08:32 AM 3/25/2009 -0500, Olemis Lang wrote:
Sometimes it also happens that, once one such build/packaging systems
is adopted, it is difficult to switch to using another one, since apps
(... and plugins systems ...) are frequently hard-coupled to the pkg
sys «exotic features» and support (...
At 07:40 AM 3/25/2009 -0700, Guido van Rossum wrote:
Well, sorry, but this complex layered interdependent architecture is
one of the *causes* of confusion -- apart from you nobody knows what
is what exactly,
I'll pick a minor nit here... buildout, pip, and a wide variety of
other tools and
At 10:11 AM 3/25/2009 -0500, Olemis Lang wrote:
... but Trac plugins *do require* egg files ... (AFAIK after reading
Trac docs and implementation of plugin upload from /admin/plugins, egg
cache for plugins ... and so on ...) and this is what I was talking
about ... apps (e.g. Trac) depending
At 01:29 PM 3/25/2009 -0400, Terry Reedy wrote:
Paul Moore wrote:
2009/3/25 Tarek Ziadé ziade.ta...@gmail.com:
Since setuptools came on the scene, I can state with some certainty
that many packages which would otherwise have been distributed as
bdist_wininst installers, now aren't. In some
At 06:08 PM 3/25/2009 -0500, Barry Warsaw wrote:
I've found setuptools entry points difficult to work with for plugins,
I'd be interested in hearing more about your specific difficulties,
although it's probably off-topic for Python-Dev. Perhaps via the
distutils-sig, since we don't have a
At 11:35 AM 3/25/2009 -0500, Olemis Lang wrote:
Yes you're right, Trac requires .egg files for local plugins installs
(... in /plugins folder ;) so that not all environments but only one
be able to use the plugin ... but that's not exactly what I'm saying,
since setuptools AFAIK *MUST* be
At 09:24 PM 3/25/2009 -0700, Guido van Rossum wrote:
ISTR that the motivation for adding new syntax is that the best you
can do using a trampoline library is still pretty cumbersome to use
when you have to write a lot of tasks and subtasks, and when using
tasks is just a tool for getting things
At 10:56 AM 3/26/2009 +, Antoine Pitrou wrote:
Guido van Rossum guido at python.org writes:
That's stating it a little too strongly. Phillip has shown how with
judicious use of decorators and helper classes you can get a
reasonable approximation, and I think Twisted uses something like
At 12:27 PM 3/26/2009 -0700, Guido van Rossum wrote:
There is some clear low-hanging fruit for Greg's proposal
where no trampoline or helpers are needed -- but where currently
refactoring complex code containing many yield statements is
cumbersome due to the nee to write each subroutine call as
At 03:28 PM 3/26/2009 -0500, Guido van Rossum wrote:
2009/3/26 Barry Warsaw ba...@python.org:
BTW, under a better name, I would support putting pkg_resources in the
stdlib.
Last time I looked it was an incredibly complicated piece of code that
would have to be refactored considerably before
At 11:27 PM 3/26/2009 +, Paul Moore wrote:
What I'd really like is essentially some form of virtual filesystem
access to stuff addressed relative to a Python package name,
Note that relative to a *Python package name* isn't quite as useful,
due to namespace packages. To be unambiguous as
At 10:39 PM 3/26/2009 -0500, Guido van Rossum wrote:
That +0 could turn into a +1 if there was a way to flag this as an
error (at runtime), at least if the return is actually executed:
def g():
yield 42
return 43
for x in g():
print x# probably expected to print 42 and then 43
At 04:08 PM 3/27/2009 +1300, Greg Ewing wrote:
You can't expect to improve something like that by
stuffing yield-from into the existing framework, because
the point of yield-from is to render the framework
itself unnecessary.
But it doesn't. You still need *something* that processes the
At 01:49 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
(*) I've had a go at this a few months ago and then found out
that the egg format itself is not documented anywhere.
It's been documented for just under three years now. Here's where
you quoted the email where I announced that documentation,
At 05:08 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
On 2009-03-27 17:01, Eric Smith wrote:
Martin v. Löwis wrote:
Correct me if I wrong, but shouldn't Python include function for
version comparisons?
On the packaging summit yesterday, people agreed that yes, we should
have something like
At 03:28 AM 3/27/2009 -0400, Scott Dial wrote:
P.J. Eby wrote:
One remaining quirk or missing piece: ISTM there needs to be a way to
extract the return value without using a yield-from statement. I mean,
you could write a utility function like:
def unyield(geniter):
try
At 11:37 PM 3/26/2009 -0500, Eric Smith wrote:
P.J. Eby wrote:
As someone else suggested, moving some of the functionality to PEP 302
interfaces would also help. Most of the code, though, deals with
locating/inspecting installed distributions, resolving version
requirements, and managing
At 08:12 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
On 2009-03-27 17:19, P.J. Eby wrote:
At 01:49 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
(*) I've had a go at this a few months ago and then found out
that the egg format itself is not documented anywhere.
It's been documented for just under
At 10:22 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
Perhaps someone should start working on a tool called FryingPan to
create Omelettes, ie. all eggs squashed into a single ZIP file... ;-)
They're called baskets actually. ;-) There's no tool to do it, but
pkg_resources does support multiple
At 03:06 PM 3/27/2009 -0500, Tarek Ziadé wrote:
They both aim at the
same goal besides a few differences, and they both rely
on a new metadata introduced by setuptools, wich is.
install_requires. This new metadata extends the metadata.
described in PEP 314 but is slightly different
At 12:53 PM 3/28/2009 +1200, Greg Ewing wrote:
Guido van Rossum wrote:
Perhaps the crux is that *if* you accidentally use return value in
a vanilla generator expecting the value to show up somewhere, you are
probably enough of a newbie that debugging this will be quite hard.
I'd like not to
At 06:52 AM 3/28/2009 -0500, Guido van Rossum wrote:
2. In addition to the yield from syntax for delegating to a
subgenerator, also add new syntax for returning values from
subgenerators so that the basic return X can continue to trigger
SyntaxError.
Since option 2 would most likely lead
At 10:32 AM 4/2/2009 -0500, Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Please comment.
An excellent idea. One thing I am not 100% clear on, is how to get
additions to sys.path to work correctly with this. Currently, when
pkg_resources adds a new egg to
At 10:33 PM 4/2/2009 +0200, M.-A. Lemburg wrote:
That's going to slow down Python package detection a lot - you'd
replace an O(1) test with an O(n) scan.
I thought about this too, but it's pretty trivial considering that
the only time it takes effect is when you have a directory name that
At 03:21 AM 4/3/2009 +0200, Matthias Klose wrote:
+1 speaking as a downstream packaging python for Debian/Ubuntu I
welcome this approach. The current practice of shipping the very
same file (__init__.py) in different packages leads to conflicts for
the installation of these packages (this is
At 10:15 PM 4/3/2009 +0200, Martin v. Löwis wrote:
I should make it clear that this is not the case. I envision it to work
this way: import zope
- searches sys.path, until finding either a directory zope, or a file
zope.{py,pyc,pyd,...}
- if it is a directory, it checks for .pkg files. If it
At 02:00 PM 4/6/2009 +0100, Chris Withers wrote:
Martin v. Löwis wrote:
Chris Withers wrote:
Would this support the following case:
I have a package called mortar, which defines useful stuff:
from mortar import content, ...
I now want to distribute large optional chunks separately, but
At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
Wouldn't it be better to stick with a simpler approach and look for
__pkg__.py files to detect namespace packages using that O(1) check ?
Again - this wouldn't be O(1). More importantly, it breaks system
packages, which now again have to deal
At 04:58 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
On 2009-04-07 16:05, P.J. Eby wrote:
At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
Wouldn't it be better to stick with a simpler approach and look for
__pkg__.py files to detect namespace packages using that O(1)
check ?
Again
At 10:51 AM 4/8/2009 -0700, Guido van Rossum wrote:
I would like it even less if an API cared about the
*actual* signature of a function I pass into it.
One notable use of callable argument inspection is Bobo, the
12-years-ago predecessor to Zope, which used argument information to
determine
At 06:52 PM 4/10/2009 +1000, Nick Coghlan wrote:
This problem (slow application startup times due to too many imports at
startup, which can in turn can be due to top level imports for library
or framework functionality that a given application doesn't actually
use) is actually the main reason I
At 05:02 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
I don't see the emphasis in the PEP on Linux distribution support and the
remote possibility of them wanting to combine separate packages back
into one package as good argument for adding yet another separate hierarchy
of special files which
At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
You are missing the point: When breaking up a large package that lives in
site-packages into smaller distribution bundles, you don't need namespace
packages at all, so the PEP doesn't apply.
The way this works is by having a base distribution
At 09:51 AM 4/15/2009 +0200, M.-A. Lemburg wrote:
On 2009-04-15 02:32, P.J. Eby wrote:
At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
You are missing the point: When breaking up a large package that lives in
site-packages into smaller distribution bundles, you don't need namespace
At 09:10 AM 4/15/2009 -0700, Aahz wrote:
For the benefit of us bystanders, could you summarize your vote at this
point? Given the PEP's intended goals, if you do not oppose the PEP, are
there any changes you think should be made?
I'm +1 on Martin's original version of the PEP, subject to the
At 06:15 PM 4/15/2009 +0200, M.-A. Lemburg wrote:
The much more common use case is that of wanting to have a base package
installation which optional add-ons that live in the same logical
package namespace.
Please see the large number of Zope and PEAK distributions on PyPI as
minimal examples
At 02:52 PM 4/15/2009 -0400, A.M. Kuchling wrote:
On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote:
Please see the large number of Zope and PEAK distributions on PyPI as
minimal examples that disprove this being the common use case. I expect
you will find a fair number of others
At 10:20 PM 4/15/2009 +0200, M.-A. Lemburg wrote:
Whether base packages are useful or not is really a side aspect
of the PEP and my proposal.
It's not whether they're useful, it's whether they're required. Your
proposal *requires* base packages, and for people who intend to use
pure
At 09:59 AM 4/16/2009 +0900, Stephen J. Turnbull wrote:
I think that for this PEP it's more important to unify
the various use cases for namespace packages than it is to get rid of
the .pth files.
Actually, Martin's proposal *does* get rid of the .pth files in
site-packages, and replaces them
At 03:46 AM 4/16/2009 +, gl...@divmod.com wrote:
On 15 Apr, 09:11 pm, p...@telecommunity.com wrote:
I think that there is some confusion here. A main package or
buildout that assembles a larger project from components is not the
same thing as having a base package for a namespace
At 03:58 AM 4/17/2009 +, gl...@divmod.com wrote:
Just as a use-case: would the Java com.* namespace be an example
of a pure package with no base? i.e. lots of projects are in it,
but no project owns it?
Er, I suppose. I was thinking more of the various 'com.foo' and
'org.bar' packages
At 05:35 PM 5/1/2009 +0100, Chris Withers wrote:
P.J. Eby wrote:
It's unclear, however, who is using base packages besides mx.* and
ll.*, although I'd guess from the PyPI listings that perhaps Django
is. (It seems that base packages are more likely to use a
'base-extension' naming pattern
At 07:41 PM 5/1/2009 +0200, Martin v. Löwis wrote:
It's unclear, however, who is using base packages besides mx.* and
ll.*, although I'd guess from the PyPI listings that perhaps Django
is. (It seems that base packages are more likely to use a
'base-extension' naming pattern, vs. the
At 04:18 PM 5/9/2009 +0200, Martin v. Löwis wrote:
Zooko O'Whielacronx wrote:
.pth files are why I can't easily use GNU stow with easy_install.
If installing a Python package involved writing new files into the
filesystem, but did not require reading, updating, and re-writing any
extant
At 04:42 PM 5/9/2009 +0200, Martin v. Löwis wrote:
If you always use --single-version-externally-managed with easy_install,
it will stop editing .pth files on installation.
It's --multi-version (-m) that does that.
--single-version-externally-managed is a setup.py install option.
Both
At 12:04 PM 5/10/2009 -0600, Zooko Wilcox-O'Hearn wrote:
The thing that prevents this from working with setuptools is that
setuptools creates a file named easy_install.pth during the python
./ setup.py install --prefix=foo if you build two different Python
packages this way, they will each
At 04:42 PM 5/9/2009 +0200, Martin v. Löwis wrote:
If you always use --single-version-externally-managed with easy_install,
it will stop editing .pth files on installation.
It's --multi-version (-m) that does that.
--single-version-externally-managed is a setup.py install option.
Both
At 12:21 AM 5/15/2009 +0200, Tarek Ziadé wrote:
Hello
I'm proposing this PEP, which has been discussed in Distutils-SIG, for
inclusion in Python 2.7 and 3.2
http://www.python.org/dev/peps/pep-0376/
Please comment !
I'd like to reiterate my suggestion that the uninstall record include
size
At 08:32 AM 5/15/2009 +0200, Jeroen Ruigrok van der Werven wrote:
Agreed. Within FreeBSD's ports the installed package registration
gets a MD5 hash per file recorded. Size is less interesting though,
since essentially this information is encapsulated within the hash.
Remove one byte from the
At 08:32 AM 5/15/2009 +0200, Tarek Ziadé wrote:
2009/5/15 P.J. Eby p...@telecommunity.com:
Ideally, a file with identical size/checksum that
belongs to more than one project should be silently left alone, and a file
installed by more than one project with *different* size/checksum should
At 06:06 PM 5/16/2009 +0200, Tarek Ziadé wrote:
Ok I've changed the PEP with all the points you mentioned, if you want
to take a look.
Some notes:
1. Why ';' separation, instead of tabs as in PEP 262? Aren't
semicolons a valid character in filenames?
2. if the installed file is located in
At 11:17 AM 5/16/2009 -0700, Glenn Linderman wrote:
On approximately 5/16/2009 9:55 AM, came the following characters
from the keyboard of P.J. Eby:
At 06:06 PM 5/16/2009 +0200, Tarek Ziadé wrote:
Ok I've changed the PEP with all the points you mentioned, if you want
to take a look.
Some
At 04:04 PM 5/19/2009 +0200, Tarek Ziadé wrote:
On Sat, May 16, 2009 at 6:55 PM, P.J. Eby p...@telecommunity.com wrote:
1. Why ';' separation, instead of tabs as in PEP 262? Aren't semicolons a
valid character in filenames?
I am changing this into a tab. for now.
What about Antoine's idea
At 05:42 PM 6/22/2009 +0200, Tarek Ziadé wrote:
Wouldn't it be better to use the native line terminator on the current
platform? (someone might want to edit or at least view the file)
Good idea, I'll change that,
As long as the file is always *read* with U mode, so that you can't
mess it
At 10:38 AM 6/23/2009 +0200, Tarek Ziadé wrote:
What about using the same names used in Python's site module:
sitedir is the name used for
a directory we named DistributionDirectory.
No, a site dir is a Python-defined directory for site-installed
packages, and/or a directory where .pth files
At 07:57 PM 6/29/2009 +0200, Tarek Ziadé wrote:
Hello,
If no one objects, I'd like to push PEP 376 in the accepted status
and go ahead with its implementation,
with continuous feedback at Distutils-SIG as we did to build it.
I do have a question about the current draft... Do zipped
At 01:34 AM 7/1/2009 +0200, Tarek Ziadé wrote:
On Wed, Jul 1, 2009 at 12:47 AM, Steven D'Apranost...@pearwood.info wrote:
I don't see how this proposal will help in the second case. If you
install distribution Spam, containing file spam.py, and then install
distribution Ham, which requires
At 07:11 AM 7/1/2009 +1000, Nick Coghlan wrote:
To address PJE's question in the PEP, it may be worth expanding on this
in the backwards compatibility section explaining how the new distutils
metadata system avoids getting confused by the old pre-standardisation
installation formats (e.g. it may
At 04:29 PM 7/1/2009 +0200, Tarek Ziadé wrote:
- Phase 1 : introduction of the egg-info file in distutils
Philipp introduced the creation of a file named xxx.egg-info file in 2006
(see http://bugs.python.org/issue1459476) alongside
distutils-installed package, that contains
the metadata of the
At 09:06 PM 7/2/2009 +0100, Paul Moore wrote:
Maybe the answer is that distutils reject *all* uses of absolute paths
on Windows. The PEP can then say whatever you want as far as I'm
concerned, as it doesn't affect me. If the existing bugs don't get
fixed, though, I'd say that the RECORD file
At 02:54 PM 7/3/2009 +0100, Paul Moore wrote:
Eggs are fundamentally a PEP 302 zip file format. There are some
extra bits of metadata for setuptools/easy_install in there (as I
understand things) but essentially they are zip files. When you say
decoupling the egg format, I assume you mean
At 12:28 AM 7/4/2009 +1000, Nick Coghlan wrote:
I suspect this limitation of the PEP 302 APIs is the origin of the
setuptools format that embeds the metadata inside the distribution - it
lets you get at the metadata without having to assume that it exists
directly on the filesystem anywhere.
I
At 12:20 PM 7/4/2009 +0900, Stephen J. Turnbull wrote:
IME, Mercurial strongly encourages a non-branching style. Although I
can't fully explain in concrete terms what makes me feel that way,
it's certainly consistent with your own inclination to advise subset
branches. Part of it comes from
At 05:26 PM 7/5/2009 +0100, Paul Moore wrote:
def get_distribution(name):
for d in get_distributions():
if d.name == name:
return d
return None
Btw, this is broken code anyway, because it's not handling
case-insensitivity or name canonicalization. (I've mentioned
At 03:13 PM 7/5/2009 +0200, Tarek Ziadé wrote:
The loader would still work with DIST_NAME.egg-info directories for
compatibility with
existing format in the query APIs, but the Distutils install command
would rather create DIST_NAME.metadata
Note that this would then break setuptools without
At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
But if it's based on PEP 302 protocols and if the pkgutil code works
with the sys.meta_path hook,
setuptools could then provide its loader, based on its EggFormats and
act as a provider without being broken.
You misunderstand me. The whole point
At 07:10 AM 7/6/2009 +1000, Nick Coghlan wrote:
By using a new name for the
directory we *guarantee* that old packaging utilities won't get confused
by the new format (they simply won't acknowledge its existence).
This is incorrect; they will get confused because they will think
that the
At 10:32 AM 7/6/2009 +0100, Paul Moore wrote:
I'm +0 on changing the name, as long as it's the *only* do it this
way because setuptools isn't going to change issue.
Please note that I never said that. I was the one who suggested
.pydist, remember?
I just don't want to have to complicate
At 04:14 PM 7/6/2009 +0100, Paul Moore wrote:
2009/7/6 Nick Coghlan ncogh...@gmail.com:
P.J. Eby wrote:
At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
But if it's based on PEP 302 protocols and if the pkgutil code works
with the sys.meta_path hook,
setuptools could then provide its loader
At 07:18 PM 7/6/2009 +0200, Tarek Ziadé wrote:
So is PEP 376 going to be able to cope with the stuff I have installed
at the moment? If not, what's the point???
If I understand Tarek's proposal correctly, then no, it will not cope.
Why that ? Can you detail ? On a system that uses only
At 07:15 PM 7/6/2009 +0100, Paul Moore wrote:
My point was that distributions which use setuptools in their
setup.py, *even if there's no runtime dependency on setuptools* end up
with non-standard .egg-info's. There is no good reason for this, from
my POV as a package user. So if setuptools is
At 07:38 PM 7/6/2009 +0100, Paul Moore wrote:
As promised, here are some open questions on PEP 376.
- Will the public API names be changed from *egginfo* to *metadata*?
+1 (FWIW, 'metadata' is what pkg_resources API refers to this kind of
stuff as.)
- What precisely are the use cases for
Just an idea... suppose that instead of using real absolute paths
in the RECORD file for non-local files (scripts, data, etc) we
changed the format to include a prefix field, containing something
like LIBDIR, SHARE, SCRIPTS, etc., ala bdist_wininst internals?
Also, we could include a
At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote:
When I started to work on this I didn't realize the gigantic amount of
work and coordination it requires
No one expects the package inquisition. ;-)
___
Python-Dev mailing list
Python-Dev@python.org
At 11:30 PM 7/7/2009 +0200, Tarek Ziadé wrote:
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Ebyp...@telecommunity.com wrote:
At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote:
When I started to work on this I didn't realize the gigantic amount of
work and coordination it requires
No one expects the
At 01:13 PM 7/8/2009 +0100, Paul Moore wrote:
An alternative solution would be for the bdist_xxx commands to ignore
the RECORD file generated in the temp area, and build its own on the
target machine when the installer is run. This is conceptuially far
cleaner, it's in line with the implicit
At 03:57 PM 7/8/2009 +0100, Paul Moore wrote:
Who's going to use the APIs based around the RECORD file? Anyone?
The distutils uninstall facility, for starters. easy_install and pip
also will, eventually.
In all three cases, the use will be in order to avoid overwriting
files belonging to
At 05:22 PM 7/8/2009 +0100, Paul Moore wrote:
2009/7/8 P.J. Eby p...@telecommunity.com:
At 03:57 PM 7/8/2009 +0100, Paul Moore wrote:
Who's going to use the APIs based around the RECORD file? Anyone?
The distutils uninstall facility, for starters. easy_install and pip also
At 01:58 PM 7/8/2009 -0400, Eric Smith wrote:
I really don't see this use case. Supporting multiple installers for
the same file (or even just trying to prevent two installers from
writing the same file)? Wouldn't you be better off just saying an
installer can't overwrite any existing file?
At 09:38 AM 7/9/2009 +0900, Stephen J. Turnbull wrote:
Eric Smith writes:
But I think we've veered into metadata that describes what has been
installed. I don't think that's so useful. As I've said, this is private
to the installers. If 2 installers want to communicate with each other
At 06:51 PM 7/8/2009 -0700, Sridhar Ratnakumar wrote:
Is there any reason why RECORD file can't be generated at runtime?
Applications can be relocatable, yet require plugins and libraries to
be upgraded, installed, uninstalled, etc.
(Also, RECORD is cross-platform to allow cross-platform
At 11:20 PM 7/8/2009 -0400, Eric Smith wrote:
P.J. Eby wrote:
ISTM that the problem that it solves is uninstall in the absence of
the original installer.
Or uninstall where the installer is setup.py install, actually.
I think we need to move away from setup.py install. It's the
antithesis
At 11:28 PM 7/8/2009 -0400, Eric Smith wrote:
Eventually, I'd like PEP 376 to support system packagers too. So
for example, if you did apt-get install python-pyqt4, then
running pip install python-pyqt4 should return without installing
anything .. as RECORD will be part of the .deb previously
At 02:46 PM 7/9/2009 -0400, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nick Coghlan wrote:
P.J. Eby wrote:
Also,
why should the RECORD file be generated at all by bdist* commands?
bdist commands that use install --root will get it as a side effect,
so they don't have
At 03:31 PM 7/10/2009 +0200, Tarek Ziadé wrote:
On Thu, Jul 9, 2009 at 9:09 PM, P.J. Ebyp...@telecommunity.com wrote:
At 02:46 PM 7/9/2009 -0400, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nick Coghlan wrote:
P.J. Eby wrote:
Also,
why should the RECORD file
At 04:11 PM 7/14/2009 -0500, Benjamin Peterson wrote:
4. When __init__() is overridden, and the subclass __init__()
calls object.__init__(), the latter should complain about
excess arguments; ditto for __new__().
Actually, this rule is a PITA, because there's no good way to get
At 07:29 PM 7/15/2009 +1200, Greg Ewing wrote:
P.J. Eby wrote:
In effect, 2.6 forces you to have a common known base class *other*
than 'object' in order to write co-operative classes. :-(
You have to do that anyway if you want to make cooperative
calls to any method *other* that __init__
At 11:10 AM 7/15/2009 +0100, Paul Moore wrote:
I propose that before the current prototype is turned into a final
(spec and) implementation, the PEP 302 extensions are extracted and
documented as an independent protocol, purely part of PEP 376. (This
*helps* implementers, as they can write
1 - 100 of 282 matches
Mail list logo
