2008/10/6 Antoine Pitrou <[EMAIL PROTECTED]>:
> Martin v. Löwis v.loewis.de> writes:
>>
>> Although it would be possible, I think it's not appropriate.
>
> I also think it's inappropriate. We want people to know about the existence of
> Python 3, and the best for that is to have Python 3-related i
2008/10/5 "Martin v. Löwis" <[EMAIL PROTECTED]>:
>>> foobar-1.0-py2.6.tar.gz
>>> foobar-1.0-py3.0.tar.gz
>>
>> More likely, in this way:
>>
>> foobar-1.0-py2.tar.gz
>> foobar-1.0-py3.tar.gz
>
> How do you implement this in distutils? People probably won't rename
> the files from how sdist names th
>> foobar-1.0-py2.6.tar.gz
>> foobar-1.0-py3.0.tar.gz
>
> More likely, in this way:
>
> foobar-1.0-py2.tar.gz
> foobar-1.0-py3.tar.gz
How do you implement this in distutils? People probably won't rename
the files from how sdist names them. So it's more likely that they
come up with things like
> Of course there is also the option of treating Python 3 as a different
> language, and having a Py3Pi website as well. This might not be as
> wasteful as it at first seems.
Although it would be possible, I think it's not appropriate.
It would be fairly easy to implement, though: just create
pyp
[Steve Holden"]
Of course there is also the option of treating Python 3 as a different
language, and having a Py3Pi website as well. This might not be as
wasteful as it at first seems.
It would be nice if we had a way of marking Py2.6 recipes that still
work when run through 2-to-3 and then au
2008/10/5 Kevin Teague <[EMAIL PROTECTED]>:
> on Python 3 after running it through 2to3. The source code is different so
> that to me suggests different version numbers - but the API will be the
> same, so maybe the same version number should be used? That is should there
> be?
>
> foobar-1.0-py2.
Martin v. Löwis wrote:
>> A problem with overloading the Categories field with Python version
>> compatability information is that it makes for a poor user-interface. On
>> the release page for a package, I'd rather see a Python Version field
>> than having to look through a potentially large list
> A problem with overloading the Categories field with Python version
> compatability information is that it makes for a poor user-interface. On
> the release page for a package, I'd rather see a Python Version field
> than having to look through a potentially large list of Categories.
That's an i
On Oct 4, 2008, at 9:59 PM, Martin v. Löwis wrote:
Setuptools declares dependencies, but does not add a Python version
requirement,
like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/
)
with a new metadata called 'Requires Python'
Even if the problem is fixed in shor
On Sun, Oct 5, 2008 at 6:59 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Setuptools declares dependencies, but does not add a Python version
>> requirement,
>> like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/)
>> with a new metadata called 'Requires Python'
>>
>>
> Setuptools declares dependencies, but does not add a Python version
> requirement,
> like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/)
> with a new metadata called 'Requires Python'
>
> Even if the problem is fixed in short term with a Trove classifier,
Why would th
On Sat, Oct 4, 2008 at 2:22 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Antoine Pitrou wrote:
>> Martin v. Löwis v.loewis.de> writes:
This may be more complicated than it sounds, because you'd probably
add a very general requirement-indicating feature to PyPI, not merely
a 's
2008/10/4 Brett Cannon <[EMAIL PROTECTED]>:
> So the mailing list is a good idea. Perhaps it should just be
> python-porting so that it can also be used for people who have
> problems with minor releases?
+1. I'd try to help on that list, also.
--
.Facundo
Blog: http://www.taniquetil.com.a
[replying to both Georg and Martin]
On Sat, Oct 4, 2008 at 12:17 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Well, since for >95% of the (potential) Py3k users it is more important than
>> e.g. the import rewrite in Python (no stab at you intended, Brett), it is
>> something someone will h
> Well, since for >95% of the (potential) Py3k users it is more important than
> e.g. the import rewrite in Python (no stab at you intended, Brett), it is
> something someone will have to get around to doing.
>
> I'm not excusing myself; in fact, I'd be happy to work on this, but overall
> the tea
Brett Cannon schrieb:
>> Last not least, there should be a *central* location on python.org where
>> specifically all resources on 2->3 transition are collected. Talks,
>> documents, links, and some crucial information many people seem to miss,
>> such as how long the 2.x series will at least be m
On Sat, Oct 4, 2008 at 12:45 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Barry Warsaw schrieb:
>> On Oct 3, 2008, at 5:26 PM, Benjamin Peterson wrote:
>>
>>> So now that we've released 2.6 and are working hard on shepherding 3.0
>>> out the door, it's time to worry about the next set of releases.
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>>> This may be more complicated than it sounds, because you'd probably
>>> add a very general requirement-indicating feature to PyPI, not merely
>>> a 'supports 3.0' Boolean on each record, and requirements are actually
>>> pretty compl
> This may be more complicated than it sounds, because you'd probably
> add a very general requirement-indicating feature to PyPI, not merely
> a 'supports 3.0' Boolean on each record, and requirements are actually
> pretty complicated: alternative packages, specific version numbers...
Can you pro
On Sat, Oct 04, 2008 at 09:45:27AM +0200, Georg Brandl wrote:
> Barry Warsaw schrieb:
> two problems: The libraries they depend on aren't ported, and the
> KLOC of code they care about are hard and tedious work to port, not
> to mention that it typically isn't viewed as productive work by those
> w
Barry Warsaw schrieb:
> On Oct 3, 2008, at 5:26 PM, Benjamin Peterson wrote:
>
>> So now that we've released 2.6 and are working hard on shepherding 3.0
>> out the door, it's time to worry about the next set of releases. :)
>
>> I propose that we dramatically shorten our release cycle for 2.7/3.1
21 matches
Mail list logo
