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.

  • @[email protected]OP
    link
    fedilink
    1
    edit-2
    23 hours ago

    more likely

    That almost sounds like you might consider to jump on polymarket, initiate the prediction, put money down on that prediction creating a position, but need a little nudge.

    Are you willing to make that bet? The size of the bet reflects how strongly you feel. Are you going to make this interesting?

    The other side of that bet would be:

    Could become that guy who extends the theory, makes a better way of doing it, and creates and publishes the package and docs.

    And the world+dog recognizes the package amongst the other tools in this genre, rather than i conforming to existing tools (uv or poetry or pip-compile-multi).

    In your favor, there are three tools. So three people/teams on this planet have presented a solution. Can count that on one hand with fingers to spare!

    On the other hand, lets keep in mind, this is a Python specific forum and everyone here are skilled super talented coders and probably full on freak’n geniuses (lifts hand, pinky to closest edge of mouth, everyone looks around at one another and copies, then looks back at you with an errie almost coordinated synchronized eye brow raise). And i oddly posted about this exact topic. Literally anyone and everyone who has commented could be that guy.

    scratches head

    looks up with one eye to check star positions

    rubs chin

    occasional alternating strong eye brow movements …

    (with hand on chin) who is this guy, should i call his bluff by taking a position? Whats the likelihood he’s secretly a closet poetry user and just some poser?

    If you won, could you be sad?

    If you lost, not get upset or ego hurt instead be much happier with the published tool over the money?

    What are the odds looking like on this particular prediction?

    Looking forward to you posting the URL to the prediction on polymarket then promoting the market to maximize your returns. First in and clean house. Rinse wash and repeat with this blowhard wannabe (referring to myself).

    • @[email protected]
      link
      fedilink
      English
      117 hours ago

      Here is another prediction: the volume of that bet would be nowhere near where it needs to be to make the bet interesting.

      Disagree? Create the bet yourself and prove me wrong.

      • @[email protected]OP
        link
        fedilink
        1
        edit-2
        6 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.

      • @[email protected]OP
        link
        fedilink
        18 hours ago

        Strategy --> deflection

        Involve other people, not yourself; reframe the discussion.

        So your predictions are worthless cuz you are unwilling to take on any risk.

        Coding involves risk and those willing to take on risk. A gambling man you are not!

        Can throw shade and FUD around all day long everyday without consequence or care. Cuz u offer nor put any skin in the game.

        Just empty words like a secretary giving a language skill assessment.

        So if i said, i see ghosts and dragons and can shit rainbows out of my butt, you’d be too weak to call the bluff.