In a requirements-*.in file, at the top of the file, are lines with -c and -r flags followed by a requirements-*.in file. Uses relative paths (ignoring URLs).

Say have docs/requirements-pip-tools.in

-r ../requirements/requirements-prod.in
-c ../requirements/requirements-pins-base.in
-c ../requirements/requirements-pins-cffi.in

...

The intent is compiling this would produce docs/requirements-pip-tool.txt

But there is confusion as to which flag to use. It’s non-obvious.

constraint

Subset of requirements features. Intended to restrict package versions. Does not necessarily (might not) install the package!

Does not support:

  • editable mode (-e)

  • extras (e.g. coverage[toml])

Personal preference

  • always organize requirements files in folder(s)

  • don’t prefix requirements files with requirements-, just doing it here

  • DRY principle applies; split out constraints which are shared.

  • logging_strictOP
    1·
    9 hours ago

    To make this interesting, you could have asked for a stipulation that i fund the other side of the bet. Oddly, you didn’t insist on that. Once the bet is funded, drop the make it interesting claim, that’s what a bet is.

    If i were in your shoes

    And believed strongly in your predictions i’d do due diligence.

    1. Read thru the persons github acnt. All the code and mercilessly, but fairly, do a public code review of all public packages, documentation, and commit style. What code quality does this person produce? Whats the likelihood this person could be prepared to possibly collaborate with others?

    This is normally enough to evaluate someone. I’ve ripped people apart who’ve presented themselves as Python coders and were actually base amateurs.

    Here is my github acnt. I submit to ur code review. Meaning, during the code review, any concerns you bring up, i have to defend my actions. Whatever public humiliation you have in store for me, cannot complain or retaliate.

    Notice there are no code of conduct files in any of the packages. Free your inner troll and be merciless!

    https://github.com/msftcangoblowm

    While there, if you like a package, star it

    1. Understand the problem

    What would it take to create a solution to this issue?

    Does the person, with that github history, clearly understand the issue? Enough to come up with a viable solution?

    If had doubts, would admit and say, not confident enough in the prediction any bet could possibly go very wrong. Could admit to having serious doubts without shame.

    If had confidence in the prediction, having conducted due diligence, would call the bluff and take the guys money

    You took the third option, get called out and proven a non-risk taker and someone who doesn’t bother doing their own research. But doesn’t mind throwing shade at everyone and everything.