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
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 nat
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 machine
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 t
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 pa
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
>> h
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"
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
>.../foo-1.0.eg
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 res
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'
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 th
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 differe
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"
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 th
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 provid
On 20-apr-2006, at 23:08, Martin v. Löwis wrote:
> 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-reada
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
> > w
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" s
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
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,
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
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
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 "zer
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 "resour
Guido van Rossum wrote:
> Anyway, perhaps it's a matter of choice. It's clear to me that many
> developers prefer to do it this way. You don't. This is an area that
> has enough external constraints that I'm uncomfortable telling
> developers they can't do it that way.
Hence my -0. I see the pract
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. Odd
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
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 migh
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 plat
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 l
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 wor
"Guido van Rossum wrote:
> > - I still fear that the code of setuptools will turn out to be
> > a maintenance nightmare.
>
> AFAICT Phillip has explicitly promised he will maintain it (or if he
> doesn't, I expect that he would gladly do so if you asked). This has
> always been sufficient as a "
Guido van Rossum 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"
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
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
>> 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 actual
36 matches
Mail list logo
