Martin v. Löwis wrote: >> 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? >> > > 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. > 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? -- Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20080319/40a13e12/attachment.htm
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4