Parsing the requirements file always needs HTTP Session object.

Parsing the requirements file should not need a HTTP Session object if there are no references to resolve. This is useful for setup.py files to avoid maintaining the same dependency list twice.

From https://stackoverflow.com/questions/14399534/reference-requirements-txt-for-the-install-requires-kwarg-in-setuptools-setup-py

from pip.req import parse_requirements

# parse_requirements() returns generator of pip.req.InstallRequirement objects
install_reqs = parse_requirements(<requirements_path>)

# reqs is a list of requirement
# e.g. ['django==1.5.1', 'mezzanine==1.4.6']
reqs = [str(ir.req) for ir in install_reqs]

setup(
    ...
    install_requires=reqs
)

The code above no longer works. This hash works:

install_reqs = parse_requirements('requirements.txt', session='hack')

[dstufft]

I’m going to close this, the current behavior is good enough for pip’s uses and uses external to pip are not supported. That this makes it more annoying for people to use outside of pip, particularly in a setup.py is really a good thing TBH.

[pfmoore]

You know that pip codebase is “not perfect”. Option parsing alone and inheritance is insane. I don’t understand what are you protecting

@techtonik I know that you have persistently failed to understand the explanations that have been offered, so I doubt that this response will fare much better, but I will try one final time to explain the position to you.

Pip’s fundamental purpose is to be a command line program that can be used to install packages for Python. That’s all. It’s not intended as a library for use by other programs, any more than it is intended to be any other thing that isn’t it’s core purpose. So anything that is important for ensuring that pip serves that primary goal of being a command line program for installing packages, is the main priority. The pip development team is very small, given the importance of pip to the Python ecosystem, and is totally unfunded, volunteer time. As a result, work on “tidying up”, or on “improving the codebase” is almost impossible to find time for. And work that implies support for something that is not pip’s key goal, and which is only likely to result in more issues being raised (specifically, making pip’s internal API more usable for 3rd party programs) is a net drain on our resources, for absolutely zero benefit for our key user base - people using pip as a command line program.

We aren’t “protecting” pip’s internal code base. We simply don’t have the time or interest to spend working on tidying up exercises that people who aren’t using pip in the way it was intended are demanding (and in some cases, relentlessly nagging about in spite of being told “this isn’t supported”).