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:
http://code.google.com/p/googleappengi
At 07:56 PM 2/22/2009 -0800, Guido van Rossum wrote:
On Sun, Feb 22, 2009 at 7:39 PM, P.J. Eby 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
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 :
> 2009/3/1 Paul Moore :
>>
>> 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 against trunk (for 2.7) at the
>
At 09:14 PM 3/2/2009 +, Paul Moore wrote:
2009/3/2 Jeffrey Yasskin :
> 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 of fixing the
iss
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"
vari
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 effec
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
frame
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.c
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 exten
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 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 example, the Tu
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 fr
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 *tod
At 01:29 PM 3/25/2009 -0400, Terry Reedy wrote:
Paul Moore wrote:
2009/3/25 Tarek Ziadé :
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 cases, only source
pack
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 pl
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 already
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 d
At 08:43 PM 3/26/2009 +1200, Greg Ewing wrote:
Trying to think of a better usage example that
combines send() with returning values, I've realized
that part of the problem is that I don't actually
know of any realistic uses for send() in the first
place.
Can anyone point me to any? Maybe it will
At 10:56 AM 3/26/2009 +, Antoine Pitrou wrote:
Guido van Rossum 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
> thi
At 12:20 PM 3/26/2009 -0700, Guido van Rossum wrote:
By brittle I meant again having to be aware of those details of the
mechanism that exist because of syntactic limitations, e.g.
accidentally writing "return X" instead of "yield Return(X)".
In that case, you'd either have a syntax error under
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 :
> 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 it would be
main
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 a
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
yield
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, p
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 someth
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
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
> requi
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&
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 multipl
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 fro
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 " 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 have s
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 like
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 s
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
mat
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 n
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 fi
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 ideal
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
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 n
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 s
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 Pytho
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 bun
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&#
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 p
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
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 packages
At 10:00 PM 4/15/2009 +0200, Tarek Ziadé wrote:
Now for the "base" or "core" package, what peoplethat uses setuptools
do most of the time:
1- they use zc.buildout so they don't need a base package : they list
in a configuration files all packages needed
to build the application, and one of th
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 pack
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' packag
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-
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. t
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.
>
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 cr
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.
>
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 a
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 fi
At 08:32 AM 5/15/2009 +0200, Tarek Ziadé wrote:
2009/5/15 P.J. Eby :
> 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 be
> warn
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.
At 04:04 PM 5/19/2009 +0200, Tarek Ziadé wrote:
On Sat, May 16, 2009 at 6:55 PM, P.J. Eby 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 . for now.
What about Antoine&#x
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
distrib
At 01:34 AM 7/1/2009 +0200, Tarek Ziadé wrote:
On Wed, Jul 1, 2009 at 12:47 AM, Steven D'Aprano 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 spam.py, what is to
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 shou
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 "de
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 t
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 t
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 witho
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 o
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 relev
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 :
> 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,
>>> setupt
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 br
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 sepa
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
htt
At 11:30 PM 7/7/2009 +0200, Tarek Ziadé wrote:
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby 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
>
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 assu
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 a
At 05:22 PM 7/8/2009 +0100, Paul Moore wrote:
2009/7/8 P.J. Eby :
> 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?
L
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
in
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 ins
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 previous
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"
At 03:31 PM 7/10/2009 +0200, Tarek Ziadé wrote:
On Thu, Jul 9, 2009 at 9:09 PM, P.J. Eby 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:
>&
1 - 100 of 291 matches
Mail list logo
