Show HN: Python requirements for Humans
github.com
Show HN: Python requirements for Humans
1–10 of 21 posts
Re: Show HN: Python requirements for Humans
#2This 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:
https://caremad.io/2013/07/setup-vs-requirement/
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).
Re: Show HN: Python requirements for Humans
#3This 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: https://caremad.io/2013/07/setup-vs-requirement/ 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 do…
ds' article has been referenced many times and I have had multiple discussions on #python myself and trust me, no one agree on a single approach.
> Also, unfortunately pip's parser for requirements.txt isn't public
I am not sure what you mean by "isn't public." The API is "private" or the parser is proprietary? or the API is not isolated to its own (like Ansible's command line parser is stuck inside a giant function). If the second I would be super surprise.
But I am with the repo author. I think we just need one format, one way to do things. The implementation however, needs to be discussed as the example code is pretty redundant in the effort, would be much nicer if we can just provide the path in setup.py and pip reads off setup.py and consume requirements.txt. For god sake this is dependency declaration, ain't package management.
Re: Show HN: Python requirements for Humans
#4How 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.
Re: Show HN: Python requirements for Humans
#5Ironically, the package to make your package requirements easier to write has additional requirements not in the core distribution :)
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).
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.
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 :)
Re: Show HN: Python requirements for Humans
#6This 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: https://caremad.io/2013/07/setup-vs-requirement/ 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 do…
ds' article has been referenced many times and I have had multiple discussions on #python myself and trust me, no one agree on a single approach. > Also, unfortunately pip's parser for requirements.txt isn't public I am not sure what you mean by "isn't public." The API is "private" or the parser is proprietary? or the API is not isolated to its own (like Ansible's command line parser is stuck inside a giant function)…
pip is not meant to be used as an API, and there is no backward compatibility guarantee, AFAIK.
There is an ongoing effort to extract all its logic into separated packages [1], thought.
Re: Show HN: Python requirements for Humans
#7How 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.
Like I say in README[0], you have to put `requirements.py` beside your `setup.py`
Re: Show HN: Python requirements for Humans
#8Ironically, the package to make your package requirements easier to write has additional requirements not in the core distribution :) 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 th…
Thank you for your feeback.
Same reasons that encourage me to build `requirements` :)
I know this isn't perfect for now, `requirements` could evolve!
Re: Show HN: Python requirements for Humans
#9I 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.
Re: Show HN: Python requirements for Humans
#10I 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.
Who's the copyright holder? How can I contact that person? What's the copyright year? Licensing software with MIT licence is trivial: http://choosealicense.com/licenses/mit/
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.
On a more personal note I started to dislike the "* for humans", it's been overused.