<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Martin v. Löwis wrote:
<blockquote cite="mid:47E11659.9000307@v.loewis.de" type="cite">
<blockquote type="cite">
<pre wrap="">1. What is the plan for PyPI when Python 3.0 comes out and
dependencies start getting satisfied from distribution
across the great divide, e.g. a 3.0-specific package
pulls from PyPI a 2.x-specific package to meet some
need? Are there plans to fork PyPI, apply special
tags to uploads or what?
</pre>
</blockquote>
<pre wrap=""><!---->
I don't see the need to for PyPI. For packages (or "distributions",
to avoid confusion with Python packages), I see two options:
a) provide a single release that supports both 2.x and 3.x.
The precise strategy to do so might vary. If one is going
for a single source version, have setup.py run 2to3
(or perhaps 3to2). For dual-source packages, have setup.py
just install the one for the right version; setup.py itself
needs to be written so it runs on both versions (which is
easy to do).
b) switch to Python 3 at some point (i.e. burn your bridges).
You seem to be implying that some projects may release separate
source distributions. I cannot imagine why somebody would want
to do that.
</pre>
</blockquote>
<br>
While not quite to the same scale as the 2 to 3 transition, this
problem seems like one that would generally already exist. If one
writes code that uses newer 2.4/2.5 features (say decorators for
example,) it won't build/run on 2.3 or earlier installs. How have
people been handling that sort of situation? Is it only by not using
the newer features or is there some situation I'm just not seeing in a
brief review of a few projects pages on PyPI where there is only one
source tarball?<br>
<br>
-- Dave<br>
<br>
</body>
</html>