This is a nice idea in theory, but setup.py and requirements.txt are not the same, and you cannot particularly generate one from the other:<p><a href="https://caremad.io/2013/07/setup-vs-requirement/" rel="nofollow">https://caremad.io/2013/07/setup-vs-requirement/</a><p>Also, unfortunately pip's parser for requirements.txt isn't public, like much of its internals at the moment, which means AIUI it's likely that the parsing code here is going to be brittle if it uses it, or miss edge cases if it doesn't. (I haven't read this carefully yet though).
Python dependency management is a hard problem, but better than most languages [citation needed]. And `pip` and `setup.py` have emerged over several years, with several influences merged in (remember distutils?).<p>Honestly, I wish you'd picked a different tag-line though (riffing on `requests` no doubt). Unlike `requests`, your solution only works for a subset of deployment situations, because - as already pointed out - `setup.py` and `requirements.txt` are for different things.<p>One of the best examples for this I've seen is to use both to deploy to a server with no internet connectivity. For development the dependencies are installed from `setup.py`. Then, before deploying, all dependencies are downloaded via `pip download`. Put the dependencies on the server, finally, use `requirements.txt` with `--no-index` and `--find-links` to install. Definitely an <i>interesting</i> setup, but needs must. Unfortunately, your solution doesn't support `--no-index`, `--find-links` and a few others.<p>You may want to have a look at tools like `pbr` (Python Build Reasonableness) [1], which has an interesting way of dealing with some hard problems. It also shows how to use `setup_requires` so you don't have to have `requirements.py` hanging around in your repo.<p>[1] <a href="http://docs.openstack.org/developer/pbr/" rel="nofollow">http://docs.openstack.org/developer/pbr/</a>
Ironically, the package to make your package requirements easier to write has additional requirements not in the core distribution :)<p>But more seriously, good idea in thinking that things should already be this way. The dual maintainance of the dependency list between setup.py and requirements.txt unfortunately leads to a lot of packages being left out of one or the other, or a package that works great from source that has a broken setup.py (which usually applies to everything I do).<p>A setup.py command for installing deps from setup.py would, to me, seem a bit more logical - but things already exist the way they do.<p>In the end though, it's a bit weird to deviate from the standard norms of package installation, at least in Python circles, which may introduce some confusion -- contrast this with Javascript circles that replace "the one true way" about every 3 months :)
I see a problem with that "License is MIT". That's not how software is licensed and if the author wants this to be used, the legal part must be flawless.<p>Who's the copyright holder? How can I contact that person? What's the copyright year? Licensing software with MIT licence is trivial: <a href="http://choosealicense.com/licenses/mit/" rel="nofollow">http://choosealicense.com/licenses/mit/</a><p>Depending on the project, if I really care about the legal status of the code I use, I may contact the author to clarify this kind of thing, but sometimes it is too much hassle. Just look at it as a critical bug in your software, and fix it.<p>On a more personal note I started to dislike the "* for humans", it's been overused.
I wish the Python community would adopt a Bundler/Gemfile style. The project.clj concept is also a fantastic approach. Environments should just be maps of data that you can modify or compose on the fly.
How would you install a package that depended on this? You can't install it's dependencies automatically until you've got one of the dependencies installed.