Local file parse failure

[cici]

A relative local file fails to parse. Example: lib/recaptcha-client-1.0.6.tar.gz

Traceback (most recent call last): File "pyreqs.py", line 77, in main() File "pyreqs.py", line 73, in main parse_graph(lines) File "pyreqs.py", line 47, in parse_graph for req in parsed_reqs: File "/Library/Python/2.7/site-packages/requirements/parser.py", line 45, in parse yield Requirement.parse(line) File "/Library/Python/2.7/site-packages/requirements/requirement.py", line 181, in parse return cls.parse_line(line) File "/Library/Python/2.7/site-packages/requirements/requirement.py", line 159, in parse_line pkg_req = Req.parse(line) File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 2510, in parse reqs = list(parse_requirements(s)) File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 2436, in parse_requirements line, p, specs = scan_list(VERSION,LINE_END,line,p,(1,2),"version spec") File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 2404, in scan_list raise ValueError("Expected "+item_name+" in",line,"at",line[p:]) ValueError: ('Expected version spec in', 'lib/recaptcha-client-1.0.6.tar.gz', 'at', '/recaptcha-client-1.0.6.tar.gz')

[davidfischer]

As the code is currently written, requirements-parser will not match local requirements which aren't specified with file:// or with #egg=. The reason for this is that it is impossible to tell whether a requirement line references a relative module or a PyPI module. Pip can tell at runtime if a file in a requirement is a relative file or a requirement specifier by checking if the file or directory actually exists. Originally, I intended requirements-parser to be able to statically analyze requirements files and so I wasn't intending for it to be run from a specific directory.

It is possible to get slightly more clever and treat any specifier with a / as a relative module and anything without as a requirement specifier but that has holes as well.

[cici]

That makes sense. I appreciate your quick reply. I will just wrap it to catch the error and deal with those few entries we have in our requirements.txt file or see if I can get everyone to add the file:// specification.

Thanks!

Ci-Ci

David Fischer wrote:

As the code is currently written, requirements-parser will not match local requirements which aren't specified with |file://| or with |#egg=|. The reason for this is that it is impossible to tell whether a requirement line references a relative module or a PyPI module. Pip can tell at runtime if a file in a requirement is a relative file or a requirement specifier by checking if the file or directory actually exists. Originally, I intended requirements-parser to be able to statically analyze requirements files and so I wasn't intending for it to be run from a specific directory.

It is possible to get slightly more clever and treat any specifier with a |/| as a relative module and anything without as a requirement specifier but that has holes as well.

— Reply to this email directly or view it on GitHub https://github.com/davidfischer/requirements-parser/issues/18#issuecomment-24969179.

[davidfischer]

I appreciate your understanding. I realize simply saying "it won't work" is somewhat unreasonable. I'm open to suggestion if you have a good idea.

[cici]

Off the top of my head, you could add a run option to pass in a directory to look for local libs (or relative to local libs). I don't think it is too much to ask to add the file:// specifier. It may just be that the standards in our development shop are a bit "loose"! :-)

David Fischer wrote:

I appreciate your understanding. I realize simply saying "it won't work" is somewhat unreasonable. I'm open to suggestion if you have a good idea.

— Reply to this email directly or view it on GitHub https://github.com/davidfischer/requirements-parser/issues/18#issuecomment-25006114.

[stuaxo]

Hi, If an entry starts with ./ then it is most definitely relative. - Just been playing with this in pip + readthedocs - it seems support is a little flakey.

S

[davidfischer]

@stuaxo sounds interesting. What exactly are you doing? It sounds interesting. I assume that pip properly handles ./, ../ and such. However, this library is intended to parse arbitrary requirements.txt files regardless of where they are on the filesystem.

[stuaxo]

I have a requirements.txt for readthedocs - which installs a sphinx extension for my app + came up with an error that looks like this one.

https://github.com/shoebot/shoebot/blob/readthedocs/doc/requirements.txt

I've since realised that ./ is actually relative to where pip is lanched from, not where the file is .. which doesn't seem helpful.

https://github.com/pypa/pip/issues/328

[madpah]

Closing as this is stale and believed to be superseded by #85 included in 0.8.0.