Lennart Regebro rege...@gmail.com writes:
If you say I need to install this package it may technically be
unclear if you mean the package foo.bar or the distribution
foo.bar-3.6.tgz, but that difference is not in that case
significant. Installing the distribution and installing the package is
On Mon, Jan 11, 2010 at 09:09, Ben Finney ben+pyt...@benfinney.id.au wrote:
Lennart Regebro rege...@gmail.com writes:
If you say I need to install this package it may technically be
unclear if you mean the package foo.bar or the distribution
foo.bar-3.6.tgz, but that difference is not in that
On 11/01/2010 6:13, David Lyon wrote:
My presumption as a long standing windows programmer is that somehow the
'i386' notation was somehow meant to be somehow related to windows. Since
in the past, windows users had intel processors and mac users had risc
(motorola) processors.
So 'i386'
On Mon, Jan 11, 2010 at 12:33, Ben Finney ben+pyt...@benfinney.id.au wrote:
Lennart Regebro rege...@gmail.com writes:
I said that it's not a big problem because in most cases the
terminology mixup does not result in any practical confusion. And I
stand by that.
So we're back to a tautology:
On Jan 10, 2010, at 7:57 PM, David Lyon wrote:
As a regular developer, I'd call for a L'Oeuf incredible. Excuse my bad
french. A new egg to replace all the bad old eggs.
We need more simplicity in packaging in python..
eggs are cool. They're simple. They're what users want. They're what
On Mon, Jan 11, 2010 at 6:53 AM, Lennart Regebro rege...@gmail.com wrote:
On Mon, Jan 11, 2010 at 12:33, Ben Finney ben+pyt...@benfinney.id.au wrote:
Lennart Regebro rege...@gmail.com writes:
I said that it's not a big problem because in most cases the
terminology mixup does not result in any
On Mon, Jan 11, 2010 at 15:27, John Gabriele jmg3...@gmail.com wrote:
Lennart, like you said, there's not much confusion for the majority of
cases where the distribution-package (distribution) contains only one
module-package.
Correct, there is not a problem in the majority of the cases, and
On Mon, Jan 11, 2010 at 9:19 AM, Barry Warsaw ba...@python.org wrote:
On Jan 10, 2010, at 7:57 PM, David Lyon wrote:
As a regular developer, I'd call for a L'Oeuf incredible. Excuse my bad
french. A new egg to replace all the bad old eggs.
We need more simplicity in packaging in python..
Ned Deily wrote:
It states in PEP 345 that the OS and CPU for which the binary
distribution was compiled is described in the Supported-Platform field.
It also says that the semantic of that field are not specified by this
PEP. Presumably the value returned by distutils.get_platform() would
On Mon, Jan 11, 2010 at 9:17 AM, John Gabriele jmg3...@gmail.com wrote:
Do you mean, change the general name of these packaged up things from
distributions to eggs? So, we'd generically refer to, say,
CheesyComestible-1.2.3.tgz as an egg?
Interesting.
What term would you use to refer
On Thursday, 2010-01-07, at 20:43 , John Gabriele wrote:
So, here's a suggestion: just call both things (packages and
distributions) packages, but then agree to fully qualify the
names when you need to avoid ambiguity, for example: I just built
a distribution-package (or dist-package for
So, what is this field for?
See the PEP:
Binary distributions containing a PKG-INFO file will use the
Supported-Platform field in their metadata to specify the OS and CPU for
which the binary distribution was compiled.
Seems very clear to me.
Can we give it a useful definition?
Useful for
Martin v. Löwis wrote:
So, what is this field for?
See the PEP:
Binary distributions containing a PKG-INFO file will use the
Supported-Platform field in their metadata to specify the OS and CPU for
which the binary distribution was compiled.
Seems very clear to me.
The question
The question what it it for? needs a better answer than that. Who
looks at this field? What do they do with the data that it contains?
When creating a record, how do I know the correct value to put in this
field? Can I just make up anything, like Supported-Platform: my new
laptop?
The
Hi,
while toying with the entrypoint system, i repeatedly ran into the need
of having additional metadata prior to importing
In Plugins that only handle certain filetypes/extensions/mimetypes might
profit from the additional metadata (while also defering imports)
The same goes for my library
On Mon, Jan 11, 2010 at 9:19 AM, Barry Warsaw ba...@python.org wrote:
Do you mean, change the general name of these packaged up things from
distributions to eggs?
What I mean is that the egg concept abstracts all the packaging
details from the user extremely well.
If a user gets told that
Martin,
py import platform
py platform.machine()
'i686'
'i686' maps very well to a real machine on the market, namely to the
machine on which I'm typing this right now.
Ok.
When I run the same thing:
import platform
platform.machine()
'x86'
So what is being proposed isn't very
Rafeal wrote:
Windows (NT) used to run also on IA-32, MIPS and PowerPC processors too,
and Windows (CE) also runs on other CPU FAMILIES other than i386 (ARM,
MIPS, Hitachi SuperH).
So, no, i386 is just a widely used name to call the subset of the x86
family that runs on 32bit (vs. the old
On Jan 11, 2010, at 8:01 PM, David Lyon wrote:
When I run the same thing:
import platform
platform.machine()
'x86'
Just as a data point, I get:
import platform
platform.machine()
'i386'
on a dual processor quad core Mac Pro.
S
___
At 11:24 PM 1/11/2010 +0100, Ronny Pfannschmidt wrote:
Hi,
while toying with the entrypoint system, i repeatedly ran into the need
of having additional metadata prior to importing
In Plugins that only handle certain filetypes/extensions/mimetypes might
profit from the additional metadata
20 matches
Mail list logo
