Le dimanche 27 novembre 2005 à 22:49 -0500, Phillip J. Eby a écrit :
Just a reminder: without the .egg-info metadata (or something similar), we
aren't fulfilling one of the primary use cases, which is Debian users
wanting their bleeding-edge installs to not duplicate stable packages.
This
On Mon, 2005-11-28 at 09:45 +0100, Josselin Mouette wrote:
Le dimanche 27 novembre 2005 à 16:26 -0600, Ian Bicking a écrit :
[...]
easy_install works, right now, for these packages. There are some
outstanding issues, and those issues can probably be resolved in
easy_install, without any
On Fri, 2005-11-25 at 08:57 -0500, Phillip J. Eby wrote:
At 10:29 AM 11/25/2005 +, Donovan Baarda wrote:
On Fri, 2005-11-25 at 01:33 -0500, Phillip J. Eby wrote:
[...]
In the case where the user is *not* using easy_install, then all
dependencies will be met by system packages, and the
Josselin Mouette wrote:
Le dimanche 27 novembre 2005 à 16:26 -0600, Ian Bicking a écrit :
No one is forcing Debian to package any of these.
Of course you are forcing Debian to package these. As long as your
projects have enough users, someone will want to build a Debian package.
The whole
Le lundi 28 novembre 2005 à 11:27 -0600, Ian Bicking a écrit :
That's okay; I'll just tell my users to use it when Debian packages are
not available (which is the case for the majority of Python libraries,
and probably always will be unless libraries are automatically
packaged).
Josselin Mouette [EMAIL PROTECTED] wrote:
Creating debs easily is a good idea if done correctly, but only for
packages that will eventually enter the archive. It's a very bad
idea to encourage people to build their own versions of Debian
packages. It would lead to a horrible cluttering of
Josselin Mouette wrote:
Again, the ability to distribute it as a single package is good,
What single package are you talking
about? http://turbogears.org/download/ lists eggs and source packages for
*10* different Python projects that it depends on, written by five
different authors. Each is
Le dimanche 27 novembre 2005 à 13:30 -0600, Ian Bicking a écrit :
You're reinventing the wheel. Really. This isn't a matter for the
Windows world, as users are accustomed to various, broken tools to
install stuff, and this one will probably be less broken than others.
But MacOS and Linux
--Phillip == Phillip J Eby [EMAIL PROTECTED] writes:
(btw Phillip, thanks muchly for your patience with this thread)
Phillip If you unpack this as-is, but rename EGG-INFO to
Phillip foobar.egg-info (today) or foobar-1.2.egg-info (when I
Phillip release 0.6a9 of setuptools), and the whole
On Thu, Nov 24, 2005 at 01:05:14PM -0500, Phillip J. Eby wrote:
What you're saying is, you want TurboGears to be able to blindly trust that
its dependencies are installed. This doesn't help users, though, because
it keeps the package author from being able to provide *end-user support*
On Thu, Nov 24, 2005 at 11:46:58AM -0500, Phillip J. Eby wrote:
At 04:20 PM 11/24/2005 +0100, Josselin Mouette wrote:
Le jeudi 24 novembre 2005 ? 10:14 -0500, Phillip J. Eby a écrit :
At 01:44 PM 11/24/2005 +0100, Josselin Mouette wrote:
They only introduce more complexity, instead of
Alle 12:34, venerdì 25 novembre 2005, Paul Moore ha scritto:
On 11/25/05, Donovan Baarda [EMAIL PROTECTED] wrote:
On thing about this worried me;
If TurboGears depends on an egg'ed ElementTree, what happens if a
system has ElementTree installed as a non-egg package? Does installing
On 11/25/05, Vincenzo Di Massa [EMAIL PROTECTED] wrote:
To me, this sucks. Sorry, Philip, I know *why* you can't introspect a
non-egg ElementTree well enough to avoid this, but it still sucks.
Please read
http://mail.python.org/pipermail/distutils-sig/2005-November/005520.html
Alle 13:52, venerdì 25 novembre 2005, hai scritto:
Le vendredi 25 novembre 2005 à 11:54 +0100, Vincenzo Di Massa a écrit :
Alle 11:04, venerdì 25 novembre 2005, David Arnold ha scritto:
But, if compatible versions of those dependencies are already installed
as Debian packages *without*
At 11:54 AM 11/25/2005 +0100, Vincenzo Di Massa wrote:
Alle 11:04, venerdì 25 novembre 2005, David Arnold ha scritto:
But, if compatible versions of those dependencies are already installed
as Debian packages *without* egg metadata, will these be ignored?
Yes, they will.
Even if it was
At 11:34 AM 11/25/2005 +, Paul Moore wrote:
On 11/25/05, Donovan Baarda [EMAIL PROTECTED] wrote:
On thing about this worried me;
If TurboGears depends on an egg'ed ElementTree, what happens if a
system has ElementTree installed as a non-egg package? Does installing
TurboGears as an egg
At 01:07 PM 11/25/2005 +0100, Janusz A. Urbanowicz wrote:
On Fri, Nov 25, 2005 at 10:29:56AM +, Donovan Baarda wrote:
On Fri, 2005-11-25 at 01:33 -0500, Phillip J. Eby wrote:
[... long informative explanation of egg...]
In particular, will an egg wrapped inside a Debian package magically
At 01:39 PM 11/25/2005 +, Paul Moore wrote:
On 11/25/05, Donovan Baarda [EMAIL PROTECTED] wrote:
Sorry... that's what I meant; don't deb an egg... install it as an egg,
outside of the Debian package management system. As an egg, it is under
development and not ready for release as a deb.
At 04:22 PM 11/25/2005 +0100, Janusz A. Urbanowicz wrote:
On Fri, Nov 25, 2005 at 09:23:04AM -0500, Phillip J. Eby wrote:
Now, it's possible for an individual coder to write an application or
library that invokes easy_install itself, but anybody can write bad code
and that's what you have a
Le mardi 22 novembre 2005 à 17:05 -0500, Phillip J. Eby a écrit :
And over the last few months, I believe we've also succeeded in stomping
most of the issues that people had with getting solid non-root
installations on their Linux distributions. So the reasons for developers
to prefer
Le mardi 22 novembre 2005 à 18:47 -0500, Phillip J. Eby a écrit :
I don't understand you here. Are you saying that it's not possible for
dpkg to do a post-install or uninstall operation like adding or removing a
line from a file?
It's possible, but it's fragile.
Of course, this creates
Le mardi 22 novembre 2005 à 15:41 -0600, Bob Tanner a écrit :
When I read the above, my knee-jerk reaction is: Where is the data to backup
this statement?
Follow up questions are:
How much slower? We talking milliseconds, seconds, minutes? Yes, there are
variables, here, but narrow them
Le mardi 22 novembre 2005 à 11:46 -0600, Ian Bicking a écrit :
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.
You are advertising this metadata a lot, but
On Thu, 2005-11-24 at 14:14 +0100, Josselin Mouette wrote:
[...]
or having multiple versions of a package
installed at the same time.
Is this a joke? Installing several versions of a package is fragile,
it's a security mistake, and takes place on the hard disk for no real
use.
This is
Am 24.11.2005 um 14:26 schrieb Josselin Mouette:
Le mardi 22 novembre 2005 à 11:46 -0600, Ian Bicking a écrit :
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.
Hi,
Christopher Lenz:
(And no, I'm not going to repeat the numerous attempts by Phillip to
politely and comprehensively explain it all.)
Sorry -- I don't buy that. I've read all these messages too, and I also
don't know what's in the metadata besides dependency information.
Debian, rpm,
Le jeudi 24 novembre 2005 à 15:19 +0100, Christopher Lenz a écrit :
You are advertising this metadata a lot, but what does it exactly
contain? If it's for dependencies, we can really live better without
them, or with a tool to convert them into .deb dependencies.
You know, it is really
Le jeudi 24 novembre 2005 à 10:14 -0500, Phillip J. Eby a écrit :
At 01:44 PM 11/24/2005 +0100, Josselin Mouette wrote:
They only introduce more complexity, instead of bringing real features.
Please read the hundreds of kilobytes of messages I've already posted on
this thread
I've read
Alright, now to the lots of (unclear) documentation you pointed me to.
Le jeudi 24 novembre 2005 à 10:14 -0500, Phillip J. Eby a écrit :
http://peak.telecommunity.com/DevCenter/setuptools#dynamic-discovery-of-services-and-plugins
At 03:49 PM 11/24/2005 +0100, Matthias Urlichs wrote:
Hi,
Christopher Lenz:
(And no, I'm not going to repeat the numerous attempts by Phillip to
politely and comprehensively explain it all.)
Sorry -- I don't buy that. I've read all these messages too, and I also
don't know what's in the
At 04:20 PM 11/24/2005 +0100, Josselin Mouette wrote:
Le jeudi 24 novembre 2005 à 10:14 -0500, Phillip J. Eby a écrit :
At 01:44 PM 11/24/2005 +0100, Josselin Mouette wrote:
They only introduce more complexity, instead of bringing real features.
Please read the hundreds of kilobytes of
Le jeudi 24 novembre 2005 à 11:46 -0500, Phillip J. Eby a écrit :
No, what's happening is that you're not paying attention, because you
believe that Debian already solves those problems, even though it doesn't
solve them for Python developers who want their projects to be usable on
every
Le jeudi 24 novembre 2005 à 11:43 -0500, Phillip J. Eby a écrit :
That's an interesting perspective, but it's viewing the world through
vendor-colored glasses. Unless the project developer is wearing similar
glasses (i.e., has decided to commit to Debian as their sole platform),
though,
At 06:03 PM 11/24/2005 +0100, Josselin Mouette wrote:
Le jeudi 24 novembre 2005 à 11:46 -0500, Phillip J. Eby a écrit :
And finally, and most importantly, you're ignoring the fact that this
discussion began because a Debian developer wanted to package a successful
egg-using project and its
Le jeudi 24 novembre 2005 à 12:49 -0500, Phillip J. Eby a écrit :
I don't really care if you accept the proposals or not; you guys need to do
whatever you think is best for Debian. I've only tried to educate you
about your options regarding eggs, framed within the assumption that you
Le jeudi 24 novembre 2005 à 14:13 -0500, Phillip J. Eby a écrit :
On the contrary, quite useful technical discussion about how to make this
work has taken place, including proposed changes *which I have accepted*
and will implement. You just haven't been participating in any of that
At 11:36 AM 11/24/2005 -0800, Robert Kern wrote:
Phillip J. Eby wrote:
Note, by the way, that those two things are the only essentials here, as
best I can tell, and I've already stated my willingness to change *how*
those two things get accomplished. For clarity, I will repeat yet again,
At 09:10 PM 11/24/2005 +0100, Josselin Mouette wrote:
A sane way, first of all, means a consistent way. Having two sorts of
Debian python packages is a no-go. Therefore, if we want to switch to a
new way of distributing packages, there has to be some serious grounds
for it. Currently, the
At 12:39 PM 11/24/2005 -0800, Robert Kern wrote:
I'm not suggesting that /usr/share/.../ should be the only place to find
.egg-info directories. Simply that pkg_resources would scan
sys.path+['/usr/share/.../'] and treat the ones found in /usr/share/.../
as if they were in
--Phillip == Phillip J Eby [EMAIL PROTECTED] writes:
Phillip Python developers would *love* to have Debian manage their
Phillip packages, they would simply like to be able to verify at
Phillip runtime that the management has in fact been done. It's not
Phillip that we don't trust you,
At 09:30 AM 11/25/2005 +1100, David Arnold wrote:
--Phillip == Phillip J Eby [EMAIL PROTECTED] writes:
Phillip Python developers would *love* to have Debian manage their
Phillip packages, they would simply like to be able to verify at
Phillip runtime that the management has in fact been
At 12:54 PM 11/25/2005 +1100, David Arnold wrote:
So, if a system package, shipped by the upstream developer as an egg, is
unpacked into a directory structure, and its metadata is maintained
in a .egg-info file somewhere in sys.path, non-system eggs will have all
they need to operate correctly?
As for terminology, you seem to suggest to use distribution where
Debian uses package. So Debian package would become Debian
distribution. This does not sound right, because Debian distribution
is the entire collection of packages that is released e.g. on a DVD-ROM.
I'll try to use project in
On 11/22/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Actually loading the module then requires decompressing
the code which takes a whole lot longer than just reading
a file from the file system.
In summary, things get slower when importing from ZIP files;
it really only makes sense for
Alle 11:08, mercoledì 23 novembre 2005, Martin v. Löwis ha scritto:
easy_deb implements this, so it seems to me it would be a simple matter
of running easy_deb to produce the .deb from the .egg. (Caveat: I have
not used easy_deb, but its author assures me that it is able to handle
the
On 11/23/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
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
At 11:08 AM 11/23/2005 +0100, Martin v. Löwis wrote:
As for terminology, you seem to suggest to use distribution where
Debian uses package. So Debian package would become Debian
distribution.
No, I'm fine with Debian package; I was using distribution in the sense
of distutils distribution,
Hi,
Phillip J. Eby:
I'm thinking that perhaps I should add an option like
'--single-version-externally-managed' to the install command so that you
can indicate that you are installing for the sake of an external package
manager that will manage conflicts and uninstallation needs. This
Phillip J. Eby wrote:
I was referring to how the distribution is *installed*. You don't use
things directly from a deb file, they have to be installed on the
system. When you install an egg, you must use one of the three forms,
or the system as a whole will not function.
That depends on
At 10:00 PM 11/23/2005 +0100, Martin v. Löwis wrote:
Phillip J. Eby wrote:
I was referring to how the distribution is *installed*. You don't use
things directly from a deb file, they have to be installed on the
system. When you install an egg, you must use one of the three forms, or
the
Hi,
Phillip J. Eby:
I'm also debating whether this option should also require the --record
option, since there might otherwise be no way for an external packaging
tool to know which files and directories belong to the installed package.
Sure there is -- you install with --root (in Debian's
On 11/23/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:53 PM 11/23/2005 +, Paul Moore wrote:
If there was a way of building a Windows installer that installed
packages in egg form, so I didn't have to use setup.py at all when
installing, just double-click on the installer, that would
--Paul == Paul Moore [EMAIL PROTECTED] writes:
My point to David was simply that egg packaging in the .egg form is
more akin to Stow than to CPAN, so most of the flaws of CPAN are
not applicable to them.
Paul Sorry, I don't know what Stow is, so that doesn't clarify things
Paul to
At 11:17 PM 11/23/2005 +, Paul Moore wrote:
OK, I see it now. I need to reread your previous posts about the 3
layouts, as understanding those would probably give me the remaining
pieces of the puzzle that I need.
To summarize, the layouts are .egg file (1) or directory (2), which both
At 10:39 AM 11/24/2005 +1100, David Arnold wrote:
But I was hoping that I could help clarify the point of view of a Debian
user, by pointing out that there's at least some part of the Debian user
community that won't like installing .egg applications unless they're
sanely converted to .debs
At 12:25 AM 11/24/2005 +0100, Matthias Urlichs wrote:
Phillip J. Eby:
I'm also debating whether this option should also require the --record
option, since there might otherwise be no way for an external packaging
tool to know which files and directories belong to the installed package.
Sure
Phillip J. Eby wrote:
snip
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.
snip
Yes, it's true, zipfile import
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);
I'm not sure of
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
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 obtain them
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
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 egg features
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 consider
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
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
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
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
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. In other
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
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,
I'm
--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 the same
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
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
75 matches
Mail list logo
