[hoov]

I'm not a fan of this.

First of all, requirements.txt is for development requirements. Runtime ones belong in setup.py.

Also, the "extras" feature is already in setup.py via extras_require.

I see no need to use this nonstandard tool when the standard tooling works.

[yeukhon]

I do this:

requirements/

    /base.txt
    /test.txt
    /docs.txt

Then in setup.py just read these requirements.txt. I just find this easier to manage all the dependencies from a single point. During development and testing code, you'd assume base.txt is what is going to production. It takes some care to commit this file, nonetheless.

I could keep a freeze version if I really want to have a full view (for debugging purpose).

[matt_wulfeck]

Not really. A package can be installed in both base and used in test, and vice versa, so you have no real confidence removing the package doesn't break anything. The best you get is explicit duplication.

[yeukhon]

Perhaps I didn't explain well. test.txt would only consist of packages such as "pytest". The name means a specific function. If you have a platform package that provides APIs for test classes, and APIs for other things like wrapper around AWS apis, then my recommendation is make them distinct package, even if they reside in the same repository. Just have a seperate setup.py. A package in simple terms is just a folder, module is a single file.