Skip to content

Instantly share code, notes, and snippets.

@dstufft

dstufft/1.py Secret

Created April 20, 2012 15:27
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dstufft/e61c97ee30192e575140 to your computer and use it in GitHub Desktop.
Save dstufft/e61c97ee30192e575140 to your computer and use it in GitHub Desktop.
# 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"
# 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"),
)
# 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
@dstufft
Copy link
Author

dstufft commented Apr 20, 2012

After writing these down and looking at them, my thoughts so far:

1: No. This doesn't look like it belongs anywhere near a Python application.
2: I'm on the fence about this one. It definitely looks like Python, and it would be easy to implement, however I worry that the fact it is/looks like Python would make people try to program in things that don't belong in this kind of file. On the other hand this file shouldn't ever get used as something like PyPI metadata so maybe the extra power would be useful.
3: I like how clean this looks. I worry about finding a good name for the "require" (maybe "require" is fine?). I don't know exactly how I feel about the inline syntax but there's no denying it looks cleaner than #2.

@jacobian
Copy link

[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

@pfmoore
Copy link

pfmoore commented Feb 2, 2015

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, ...)

@Julian
Copy link

Julian commented Feb 2, 2015

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")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment