Martin wrote:
> If there is no way to install the package directly into site-packages
> using the provided setup.py, I think setup.py should be
> modified/ignored.
Bob wrote:
> Won't this mean a total re-write of cdbs since it specifically looks for
> setup.py?
Matthias Klose wrote:
> yes, if cdb
Phillip J. Eby wrote:
Note also that in many cases, the package will be a single .egg file,
(analagous to a Java .jar file) rather than a directory, and files are
preferable to directories in most cases as they make Python import
processing faster.
Yes, it's true, zipfile import processing i
Phillip J. Eby wrote:
> At 01:04 AM 11/22/2005 -0600, Bob Tanner wrote:
>
>>On Tuesday 22 November 2005 12:15 am, Martin v. Löwis wrote:
>>
>>>I don't think Debian should use the egg structure. It apparently relies
>>>on building a long sys.path (even though through only a single .pth
>>>file);
>>
M.-A. Lemburg wrote:
Finally, I think it's important to note that what Debian should or should
not use isn't really relevant to Debian's users, who will quite simply need
eggs for many packages. If Debian doesn't provide them, the users will be
forced to obtain them elsewhere. Over time, the
Phillip J. Eby wrote:
Yes, it's true, zipfile import processing is faster than normal import
processing; it is in fact one of the reasons zipfile imports were added
to Python, because the zip directories are cached. A zipfile import
lookup is a single dictionary lookup, whereas a directory imp
Ian Bicking wrote:
Maybe an easier way to understand this (at least my impression) is that
zip files are treated as read-only. Any directory on sys.path gets
scanned everytime a new module is imported. And you never know if
someone added something, so you do it all over again each time. A zi
Ian Bicking wrote:
> M.-A. Lemburg wrote:
>
>>> Finally, I think it's important to note that what Debian should or
>>> should not use isn't really relevant to Debian's users, who will
>>> quite simply need eggs for many packages. If Debian doesn't provide
>>> them, the users will be forced to obt
Sanghyeon Seo wrote:
>> yes, if cdbs doesn't allow that. you don't have to use cdbs. it's not
>> a goal to adopt our packaging policies to the way cdbs currently
>> works.
>
> No, not at all.
>
> DEB_PYTHON_SETUP_CMD := debian/setup.py
> Write your own setup.py under debian/.
Nice. I see that a
M.-A. Lemburg wrote:
Eggs give room for package metadata that doesn't exist otherwise.
Putting dependencies aside, this is functionality that simply doesn't
exist with the standard distutils installation. In the case of
FormEncode, it doesn't make use of any egg features (except that other
packa
Ian Bicking wrote:
>>>Eggs give room for package metadata that doesn't exist otherwise.
>>>Putting dependencies aside, this is functionality that simply doesn't
>>>exist with the standard distutils installation.
>> Understood, but wouldn't it be reasonably possible to
>> also install this meta
Bob Tanner wrote:
An egg and Python packages don't map 1-to-1. An egg can contain
multiple packages (which is fairly uncommon so far), but also a
top-level package can exist in more than one egg (i.e., namespace
packages, like zope.interfaces or paste.script). The metadata belongs
to the egg, n
At 02:32 PM 11/22/2005 -0600, Bob Tanner wrote:
The ultimate goal is to debianize TurboGears, reading the above, and other
posts using the legacy site-packages (non-egg) installation will "break"
TurboGears?
If by that you mean, will you be able to create a Debian-packaged
TurboGears without e
Ian Bicking wrote:
> M.-A. Lemburg wrote:
>
>>> Eggs give room for package metadata that doesn't exist otherwise.
>>> Putting dependencies aside, this is functionality that simply doesn't
>>> exist with the standard distutils installation. In the case of
>>> FormEncode, it doesn't make use of any
On Tuesday 22 November 2005 03:27 pm, M.-A. Lemburg wrote:
> In summary, things get slower when importing from ZIP files;
> it really only makes sense for applications that have a long
> run time and where startup is not that important, e.g.
> Zope et al.
I was going to stay out of this discussion
Phillip J. Eby wrote:
> At 06:33 PM 11/22/2005 +0100, M.-A. Lemburg wrote:
>
>>Phillip J. Eby wrote:
>>
>>>Yes, it's true, zipfile import processing is faster than normal import
>>>processing;
>>
>>Only after *all* ZIP files on sys.path have been scanned
>>for their contents. The more you add to s
At 09:54 PM 11/22/2005 +0100, M.-A. Lemburg wrote:
In order to keep compatibilty with the existing wide-spread
approach to install packages in site-packages/ using "python setup.py
install", it should be possible (and I believe this should be the
default to not disrupt existing usage and document
On Nov 22, 2005, at 1:27 PM, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
Note by the way that "scan all these ZIP files" is a misleading
term in any
case - the files are not "scanned". They are opened, and a small
amount of
data is read from the end of the file. Nothing that I would consid
M.-A. Lemburg wrote:
Doesn't the standard "python setup.py install" work with
eggified packages anymore (meaning that the package is
installed as normal site-packages package) ?
No. First, an eggified package tries to download ez_setup
first, i.e. it won't do the distutils setup(), but the easy
At 02:00 PM 11/22/2005 -0600, Ian Bicking wrote:
An egg and Python packages don't map 1-to-1. An egg can contain multiple
packages (which is fairly uncommon so far), but also a top-level package
can exist in more than one egg (i.e., namespace packages, like
zope.interfaces or paste.script). T
Phillip J. Eby wrote:
If you have many zipfiles on sys.path, all applications will suffer
from having to read the TOC of all those zipfiles, even if they need
none of them. OTOH, if you had packages inside site-python, the
contents of the unused packages is simply ignored.
I'm sorry, but this
Phillip J. Eby wrote:
This is simply not true. If you don't believe PEP 302 and site.py,
measure it for yourself. The *only* addition to startup is the time to
actually read the .pth file and append the entries to the list.
I did. strace shows that all zip files are loaded.
And how often do
Phillip J. Eby wrote:
Debian should provide the packages, but not as eggs.
For packages that only operate as eggs, and/or require their
dependencies as eggs, you are stating a contradiction in terms. Eggs
are not merely a distribution format, any more than Java .jar files are.
So I should
M.-A. Lemburg wrote:
The main argument for using ZIP imports is to easy
distribution of complete pure-Python packages, not
a performance gain.
Precisely. For this reason, python2x.zip is on sys.path,
allowing you to include the entire library (subset) in
a single file.
It may also be of conven
Bob Tanner wrote:
When I read the above, my knee-jerk reaction is: Where is the data to backup
this statement?
One could show strace outputs, and compare the number of system calls.
Compiling this into actual timing is difficult: you would have to trade
stat calls for read calls, and you would
Phillip J. Eby wrote:
The only thing that occurs to me as even a possibility would be some
kind of frequently-used system administration utility, like if you were
going to rewrite all the bash builtin commands as Python scripts.
This whole discussion is not about whether the start time actuall
At 11:56 PM 11/22/2005 +0100, Martin v. Löwis wrote:
Phillip J. Eby wrote:
Debian should provide the packages, but not as eggs.
For packages that only operate as eggs, and/or require their dependencies
as eggs, you are stating a contradiction in terms. Eggs are not merely a
distribution for
On Tue, 22 Nov 2005, "Martin v. Löwis" wrote:
> > As
> > I've already stated, applying this same policy to Java libraries would
> > be to demanding that all the .class files be extracted to the filesystem
> > and any manifest files be deleted, before Debian would consent to
> > package them. I
On Tue, 22 Nov 2005, Phillip J. Eby wrote:
> At 11:56 PM 11/22/2005 +0100, Martin v. Löwis wrote:
> >Phillip J. Eby wrote:
> >>>Debian should provide the packages, but not as eggs.
> >>
> >>For packages that only operate as eggs, and/or require their dependencies
> >>as eggs, you are stating a co
On Tue, 22 Nov 2005, John J Lee wrote:
[...]
> Actually, I believe this is the eventual primary intended mode of
> operation of eggs. In that case, the necessary sys.path manipulation is
> handled either by setuptools' wrapper scripts / wrapper .exe files calling
> require(version), or by calling
At 11:51 PM 11/22/2005 +, John J Lee wrote:
1. Does the above affect your concern about reading many zip files?
2. I understand your concern about memory usage (though the above seems to
make it a non-issue in practice, if used sensibly), but I must have missed
the argument you made for setu
Phillip J. Eby wrote:
Debian should provide the packages, but not as eggs.
For packages that only operate as eggs, and/or require their
dependencies as eggs, you are stating a contradiction in terms. Eggs
are not merely a distribution format, any more than Java .jar files are.
So I shoul
Phillip J. Eby wrote:
I find that surprising, since I only use CGI if I'm not concerned about
the start time. It's not like there aren't dozens of "long-running
process" solutions for Python web apps including mod_python, FastCGI,
SCGI, Twisted, and even ReadyExec, to fit almost every conceiva
On Wed, 23 Nov 2005, "Martin v. Löwis" wrote:
[...]
> I don't see how the maintainer could use the dependency information
> in the egg files.
The maintainers could use the dependency information in the egg files by
writing a tool to automatically map from the egg dep info to whatever
format their
Martin v. Löwis wrote:
[...]
>
> This whole discussion is not about whether the start time actually
> matters - it is about whether it is a fact or not that eggs improve
> the startup. Some people said it does, others said it doesn't, and this
> is just the finding-of-facts phase.
>
> Anyway,
>
-->"Phillip" == Phillip J Eby <[EMAIL PROTECTED]> writes:
Phillip> This is a major advantage over developers who do not do this,
Phillip> not only in developer effectivness, but also because a
Phillip> developer who depends exclusively on a specific packaging
Phillip> system will not have
At 01:21 AM 11/23/2005 +0100, Martin v. Löwis wrote:
Phillip J. Eby wrote:
Debian should provide the packages, but not as eggs.
For packages that only operate as eggs, and/or require their
dependencies as eggs, you are stating a contradiction in terms. Eggs
are not merely a distribution fo
At 01:40 AM 11/23/2005 +0100, Martin v. Löwis wrote:
Phillip J. Eby wrote:
I find that surprising, since I only use CGI if I'm not concerned about
the start time. It's not like there aren't dozens of "long-running
process" solutions for Python web apps including mod_python, FastCGI,
SCGI, Twi
At 11:53 AM 11/23/2005 +1100, David Arnold wrote:
-->"Phillip" == Phillip J Eby <[EMAIL PROTECTED]> writes:
Phillip> This is a major advantage over developers who do not do this,
Phillip> not only in developer effectivness, but also because a
Phillip> developer who depends exclusively on a
Bob Tanner wrote:
>> I don't think Debian should use the egg structure. It apparently relies
>> on building a long sys.path (even though through only a single .pth
>> file);
>
> I'm not sure of how .eggs are implemented, but I'm going to cross-post
> this info to the python-distutils mailing list
39 matches
Mail list logo
