On 20 Apr, 2006, at 22:07, Martin v. Löwis wrote:
Guido van Rossum wrote:
This is another area where API standardization is
important; as soon as modules are loaded out of a zip file, the
traditional approach of looking relative to os.path.dirname(__file__)
no longer works.
2. standardize
On 4/23/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 01:19 PM 4/23/2006 +1000, Anthony Baxter wrote:
On Sunday 23 April 2006 11:43, Nick Coghlan wrote:
Maybe we need something that's the equivalent of alien (rpm - dpkg
converter), so that given an egg, one can easily get a native
On 20-apr-2006, at 23:46, Martin v. Löwis wrote:
Bob Ippolito wrote:
'There are several binary formats that embody eggs, but the most
common
is '.egg' zipfile format, because it's a convenient one for
distributing
projects.'
'.egg files are a zero installation format for a Python
Ronald Oussoren wrote:
On 20-apr-2006, at 23:46, Martin v. Löwis wrote:
So if this attitude (Python Eggs are the preferred binary distribution
format) is wrong, it is the attitude that has to change first. Changes
to the documentation follow from that. If the attitude is right, I'll
have to
On Sunday 23 April 2006 11:43, Nick Coghlan wrote:
Maybe we need something that's the equivalent of alien (rpm - dpkg
converter), so that given an egg, one can easily get a native
installer for that egg.
An 'eggconvert' that used the existing bdist_foo machinery to build
system specific
At 01:19 PM 4/23/2006 +1000, Anthony Baxter wrote:
On Sunday 23 April 2006 11:43, Nick Coghlan wrote:
Maybe we need something that's the equivalent of alien (rpm - dpkg
converter), so that given an egg, one can easily get a native
installer for that egg.
An 'eggconvert' that used the
Anthony Baxter wrote:
On Sunday 23 April 2006 11:43, Nick Coghlan wrote:
Maybe we need something that's the equivalent of alien (rpm - dpkg
converter), so that given an egg, one can easily get a native
installer for that egg.
An 'eggconvert' that used the existing bdist_foo machinery to
Martin v. Löwis wrote:
Some libraries (not necessarily in Python) have gone the path of
providing a unified API for all kinds of file stream access,
e.g. in KDE, any tool can open files over many protocols, without
the storage being mounted locally.
Maybe a compromise would be to provide an
Guido van Rossum wrote:
You
can't blame KDE for providing mechanisms that only work in the KDE
world. It's fine for Python to provide Python-specific solutions for
issues that have no cross-platform native solution.
Also keep in mind that we're talking about resources
used internally by the
Martin v. Löwis wrote:
Greg Ewing wrote:
The resources name is actually quite a common meme;
I believe it goes back to the original Macintosh,
I can believe that history. Still, I thought a resource
is something you can exhaust;
Haven't you heard the term renewable resource ?-)
In the
Martin v. Löwis wrote:
I can readily believe that package authors indeed see this as
a simplification, but I also see an increased burden on system
admins in return.
There are two conflicting desires here. Package authors
don't want to have to make M different kinds of package
for M different
Phillip J. Eby wrote:
By now, however, the term is popularly used with GUI toolkits of all
kinds to mean essentially read-only data files that are required by a
program or library to function, but which are not directly part of the
code.
It's just occurred to me that there's another
Ronald Oussoren wrote:
That doesn't require Eggs to be single-file zipfiles; deleting a
directory would work just as will (and I believe it will work with
ez_install, too).
Egg directories (which are basically just the same as packages using
.pth files) also work for this and that's what I
Greg Ewing wrote:
Guido van Rossum wrote:
You
can't blame KDE for providing mechanisms that only work in the KDE
world. It's fine for Python to provide Python-specific solutions for
issues that have no cross-platform native solution.
Also keep in mind that we're talking about resources
At 06:43 PM 4/21/2006 +0200, Martin v. Löwis wrote:
They might need to be available outside Python. Two use cases:
1. The application embeds an sqlite database. Even though it
knows how to get at the data, it can't use it, because the
sqlite3 library won't accept
I don't understand it.
Have you read the manuals?
You mean,
http://peak.telecommunity.com/DevCenter/setuptools
Yes, I did. However, this would only enable me to use it (should I
ever find a need). What I really need to understand is how all this
stuff works inside.
Now, I haven't actually
On Thursday 20 April 2006 17:42, Martin v. Löwis wrote:
4. .egg files. -1
As far as I understand it, an egg file is just a zipimport format zip
file with some additional metadata. You can also install the egg
files in an unpacked way, if you prefer that. I don't understand the
objection here
On 4/20/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
3. package resources. I dislike the term resources (it is not about
natural gas, water, main memory, or processor cycles, right?);
instead, this seems to provide access to embedded data files.
Apparently, there is a need for it, so
Anthony Baxter wrote:
4. .egg files. -1
As far as I understand it, an egg file is just a zipimport format zip
file with some additional metadata. You can also install the egg
files in an unpacked way, if you prefer that. I don't understand the
objection here - it's no better or worse
Guido van Rossum wrote:
This is another area where API standardization is
important; as soon as modules are loaded out of a zip file, the
traditional approach of looking relative to os.path.dirname(__file__)
no longer works.
Certainly. However, I get two conclusions out of this:
1. don't load
On 20-apr-2006, at 21:53, Martin v. Löwis wrote:
However, this isn't really my objection to .egg files. I dislike them
because they compete with platform packages: .rpm, .msi, .deb.
As far as I understand the issues they compete up to a point, but should
also make it easier to create
Bob Ippolito wrote:
They DO NOT compete any more than source packages do. eggs are packages
plus metadata, nothing more. What eggs do and what rpm/msi/deb does are
orthogonal. It's entirely reasonable that in the future rpm/msi/deb
will simply be a delivery mechanism for eggs.
That might
On 4/20/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
1. don't load packages out of .zip files. It's not that bad if
software on the user's disk occupies multiple files, as long as
there is a convenient way to get rid of them at once.
Many problems go away if you just say no to
Ronald Oussoren wrote:
As far as I understand the issues they compete up to a point, but should
also make it easier to create platform packages that contain proper the
proper dependencies because those are part of machine-readable meta-data
instead of being written down in readme files. Oddly
Greg Ewing wrote:
The resources name is actually quite a common meme;
I believe it goes back to the original Macintosh, which
was the first and only computer in the world to have files
with something called a resource fork. The resource fork
contained pieces of data called resources.
I can
Bob Ippolito wrote:
'There are several binary formats that embody eggs, but the most common
is '.egg' zipfile format, because it's a convenient one for distributing
projects.'
'.egg files are a zero installation format for a Python package;'
single modules are also such a zero installation
At 10:59 PM 4/20/2006 +0200, Martin v. Löwis wrote:
Bob Ippolito wrote:
They DO NOT compete any more than source packages do. eggs are packages
plus metadata, nothing more. What eggs do and what rpm/msi/deb does are
orthogonal. It's entirely reasonable that in the future rpm/msi/deb
At 11:26 PM 4/20/2006 +0200, Martin v. Löwis wrote:
Greg Ewing wrote:
The resources name is actually quite a common meme;
I believe it goes back to the original Macintosh, which
was the first and only computer in the world to have files
with something called a resource fork. The resource
On 4/20/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
I thought a resource
is something you can exhaust; the fork should have been
named data fork or just second fork.
Hmm... I don't think that the English word resource necessarily
implies that it can be exhausted. In US businesses, people are
Guido van Rossum wrote:
On 4/20/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
1. don't load packages out of .zip files. It's not that bad if
software on the user's disk occupies multiple files, as long as
there is a convenient way to get rid of them at once.
Many problems go away if
Phillip J. Eby wrote:
What I'm opposed to in making setuptools install things the distutils way
by default is that there is no easy path to clean upgrade or installation
in the absence of a system packaging tool like RPM or deb or
what-have-you. I am not opposed to doing the classic style
At 12:32 AM 4/21/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
What I'm opposed to in making setuptools install things the distutils way
by default is that there is no easy path to clean upgrade or installation
in the absence of a system packaging tool like RPM or deb or
32 matches
Mail list logo
