1.py

# Proposal #1
#  This attempts to closely match the Gemfiles from Bundler, this might mean that
#   people would find it easier to pick up. However it could also mean that people
#   will think down of it as a "copy" and the differences might be noticed more since
#   The syntax is matched better.
source "https://simple.crate.io"
source "https://pypi.python.org/simple/"

dist "requests"
dist "Django", "~>1.4"
dist "pinax", git = "git://github.com/pinax/pinax.git", branch = "1.4"
dist "crate", path = "~/blech"
dist "test", group = "development"
dist "test2", group = ["development", "testing"]

group "development":
    dist "blah"

2.py

# Proposal #2
#  This proposal takes the ideas from a Gemfile, and makes them more "Pythonic".
#   Instead of creating a DSL, simple functions are used. This shares a lot of the
#   same benefits as #1 in that people might find it easier to pick up as some will
#   already know Gemfiles. An obvious negative is that it tends to be a bit more verbose
#   than #1.
source("https://simple.crate.io")
source("https://pypi.python.org/simple/")

dist("requests")
dist("Django", "~>1.4")
dist("pinax", git="git://github.com/pinax/pinax.git", branch="1.4")
dist("crate", path="~/blech")
dist("test", group="development")
dist("test2", group=["development", "testing"])


group("development",
    dist("blah"),
)

3.yml

# Proposal #3
# This proposal takes the power introduced via 1 and 2, but uses yaml to create a
#  (hopefully) easy to parse set of requirements. The given example makes heavy
#  use of inline style of declaration so that one line == one dependency. One area of
#  concern is how to handle the "default" group. It will need to exist somehow. As a simpler
#  way here the default group can be defined outside of a groups: tag, but the question remains
#  what should that tag be called?
sources:
  - https://simple.crate.io
  - https://pypi.python.org/simple/

require:
  - requests
  - [Django, ~>1.4]
  - [Pinax, {git: "git://github.com/pinax/pinax.git", branch: 1.4}]
  - [crate, {path: ~/blech}]
  - [test, {group: development}]
  - [test2, {group: [development, testing]}]

groups:
  development:
    - blah
  
  

[sources]
https://simple.crate.io
https://pypi.python.org/simple/

[require]
requests
Django = 1.4
Pinax = git://github.com/pinax/pinax.git@1.4
crate = file:///...
test = group(development)
test2 = group(development, testing)

[group: development]
blah

Version 1 - Agreed, no.

Version 2 - Someone is bound to write general Python in there:

    # I like my old requirements.txt format
    with open("requirements.txt") as f:
        for req in f:
            dist(req)

I can already think of things people are going to expect to be able to do. Either it works (and we have all the problems of setup.py) or it doesn't, in which case it shouldn't look like Python.

Version 3 - Looks great. I like YAML as a user format. Pity there's no YAML parser in the stdlib, this becomes yet another thing to vendor. (I'm starting to feel like I should do from pip._vendor import thing_i_wish_was_in_the_stdlib :-()

Ini-style Version - Looks nice for the simple cases, but I suspect it will rapidly get messy (complex version specs, extras, ...)

So I'm definitely not following these discussions closely, but what is the actual solution going forward for non-universal dependencies? What is the solution for "I depend on XYZ on PyPy", and "ABC on windows", and "EFG" on python 2.6?

EDIT: (If not "just Python")