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 them. So it's more
2008/10/6 Antoine Pitrou [EMAIL PROTECTED]:
Martin v. Löwis martin at 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
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
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 of
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?
[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
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
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
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
to
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
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
who
Antoine Pitrou wrote:
Martin v. Löwis martin at 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
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
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. :)
I
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 team
[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 have to get
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:
On Sat, Oct 4, 2008 at 2:22 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
Antoine Pitrou wrote:
Martin v. Löwis martin at 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
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 that be
19 matches
Mail list logo
