Hey,
Thanks to all sprinters, this was fun. Another sprint will be soon planned.
I'd like to write a wrapup of the sprint we've done, so we can explain
what's been done and what's next.
If you were at that sprint and a "nominated" leader of one of the
team, please add a summary of what has been
On Wed, 21 Oct 2009 14:28:06 +0200, Piotr Ozarowski
wrote:
> Sure, one could just:
>
> | try:
> | import setuptools
> | except ImportError:
> | import ez_setup
> | ez_setup.use_setuptools()
>
> and thus use installed version if it's available (replace
> ez_setup/setuptools with what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
M.-A. Lemburg wrote:
> Tarek Ziadé wrote:
>> On Wed, Oct 21, 2009 at 10:42 AM, M.-A. Lemburg wrote:
>>> Tarek Ziadé wrote:
On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg wrote:
>>> The micro-language should provide a limited number of
>>
On Wed, Oct 21, 2009 at 1:38 PM, Eric Smith wrote:
> Tarek Ziadé wrote:
>>
>> On Wed, Oct 21, 2009 at 10:42 AM, M.-A. Lemburg wrote:
>>>
>>> Tarek Ziadé wrote:
On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg wrote:
>>>
>>> The micro-language should provide a limited number of
>>
2009/10/21 Sridhar Ratnakumar :
[...]
> I suggest to first have a standard library module/api that would give such
> 'friendly' names. This is what `platinfo` is heading towards:
> http://code.google.com/p/platinfo/wiki/FutureWork .. to quote:
>
[...]
I think we should focus here on what Python's
[David Lyon, 2009-10-21]
> On Wed, 21 Oct 2009 11:24:12 +0200, Piotr Ozarowski
> wrote:
> > and when there's a bug in this module you want all packages to be
> > reuploaded instead of uploading the one with a bug?
> >
> > We already have to patch setup.py files f.e. to remove ez_setup which
> > h
On Wed, 21 Oct 2009 16:48:41 +0530, David Lyon
wrote:
My original point was only that 'win32' constant from the stdlib sys
module
is an
inaccurate constant to describe windows now. The stdlib platform module
uses
'Windows' and that seems better.
+1
I suggest to first have a standard libr
Tarek Ziadé wrote:
On Wed, Oct 21, 2009 at 10:42 AM, M.-A. Lemburg wrote:
Tarek Ziadé wrote:
On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg wrote:
The micro-language should provide a limited number of
variables to use on the conditions:
python_version = sys.version
sys_platform = sys.platfo
On Wed, 21 Oct 2009 10:48:00 +0200, Tarek Ziadé
wrote:
> So do you have a use case where a Python distribution needs to use "64
> bit (the machine)"
> in order to provide a different requires ?
I wouldn't be too worried about this '64' bit issue.
Hypothetically, C library extensions can/could b
On Wed, 21 Oct 2009 11:24:12 +0200, Piotr Ozarowski
wrote:
> Hi list,
>
> I'm a Debian developer who is interested in changes you want to
> introduce so I'll add my 2 cents from time to time if you don't mind.
Hello. Yes, a virtual 2c is valuable. Certainly the best offer I've had
all day..
> a
Tarek Ziadé wrote:
> We said earlier that we could use sys.hexversion to handle this, but
> otherwise,
> at least for the Python version, we can use the StrictVersion() class
> from Distutils,
>
> *But* we ended up thinking that it would be better for the first version to
> keep
> just "==", "!="
Tarek Ziadé wrote:
> On Wed, Oct 21, 2009 at 10:42 AM, M.-A. Lemburg wrote:
>> Tarek Ziadé wrote:
>>> On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg wrote:
>> The micro-language should provide a limited number of
>> variables to use on the conditions:
>>
>> python_version = sys.ve
On Wed, Oct 21, 2009 at 10:42 AM, M.-A. Lemburg wrote:
> Tarek Ziadé wrote:
>> On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg wrote:
> The micro-language should provide a limited number of
> variables to use on the conditions:
>
> python_version = sys.version
> sys_platform =
Hi list,
I'm a Debian developer who is interested in changes you want to
introduce so I'll add my 2 cents from time to time if you don't mind.
[Chris Withers, 2009-10-21]
> David Lyon wrote:
>>> Why is it that you basically want to put an entire module's worth of
>>> code inside every single pa
On Wed, Oct 21, 2009 at 10:58 AM, David Cournapeau
wrote:
> Tarek Ziadé wrote:
>> The micro-language, though, is about the metadata fields like "requires"
>>
>> So do you have a use case where a Python distribution needs to use "64
>> bit (the machine)"
>>
>
> Given the difficulty, I think such a
Tarek Ziadé wrote:
> The micro-language, though, is about the metadata fields like "requires"
>
> So do you have a use case where a Python distribution needs to use "64
> bit (the machine)"
>
Given the difficulty, I think such a field should only be added once
python itself has a method to reli
Chris Withers wrote:
> The thing is, there's just no need for all this code to be in setup.py.
>
> For me, anything more than:
>
> from xxx import setup
> setup()
>
> ...in the case where all the information is in setup.cfg is totally
> unacceptable.
FWIW, I have played a bit with something in tha
On Wed, Oct 21, 2009 at 10:20 AM, David Cournapeau
wrote:
> Tarek Ziadé wrote:
>> There's something unclear for me here :
>>
>> What is suppose to happen when you use Python 32bits on a 64bits machine,
>> for Python distributions that get build or installed ?
>>
>> Do you end up in a mixed environ
Tarek Ziadé wrote:
> On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg wrote:
The micro-language should provide a limited number of
variables to use on the conditions:
python_version = sys.version
sys_platform = sys.platform
>>>
>>> If we adopt such a micro-language (I'm rese
Tarek Ziadé wrote:
> There's something unclear for me here :
>
> What is suppose to happen when you use Python 32bits on a 64bits machine,
> for Python distributions that get build or installed ?
>
> Do you end up in a mixed environment of 64bits distributions within a
> 32bits interpreter ?
>
On Wed, 21 Oct 2009 09:02:40 +0100, Chris Withers
wrote:
>> If the file is 100kb long, I don't think a user would care.
>
> I'm "a user" in this case, and I care... The maintenance burden a file
> like the setup.py you're proposing places on me as a package author in
> making sure the package
On Wed, Oct 21, 2009 at 3:45 AM, David Cournapeau
wrote:
> Tarek Ziadé wrote:
>> No, the architecture is given by platform.machine() so you have it already,
>> by combining a test with sys.platform.
>
> But platform.machine() returns a 32 bits machine if you run 32 bits
> python on 64 bits windows
On Wed, 21 Oct 2009 08:24:06 +0100, Chris Withers
wrote:
> David Lyon wrote:
>> Well I put my code up here:
>>
>> https://bitbucket.org/djlyon/original-setup.py-with-metadata/
>
> The thing is, there's just no need for all this code to be in setup.py.
>
> For me, anything more than:
>
> from x
David Lyon wrote:
Why is it that you basically want to put an entire module's worth of
code inside every single package's setup.py?
Because it is easy.
Let me put it another way - how does a 'normal-user' update distutils
in the stdlib?
easy_install/pip/etc distutils
...with the new versi
On Wed, 21 Oct 2009 08:29:02 +0100, Chris Withers
wrote:
> David Lyon wrote:
>> So I will build an option in to check on the net for an updated
>> version before starting.
>
> That won't fly.
but it will most definitely work...
and it will be backwards compatable with older python installations
David Lyon wrote:
So I will build an option in to check on the net for an updated
version before starting.
That won't fly.
A significant number of people will be installing in situations where
setup.py will have no access to the internet.
Why is it that you basically want to put an entire m
David Lyon wrote:
Well I put my code up here:
https://bitbucket.org/djlyon/original-setup.py-with-metadata/
The thing is, there's just no need for all this code to be in setup.py.
For me, anything more than:
from xxx import setup
setup()
...in the case where all the information is in setup.
27 matches
Mail list logo
