Pinning requirements

[themanifold]

As per the pip-tools guidelines and good practice, I would request that the dependencies for pymsteams be pinned. For the production application, these would be from setup.py:

• requests>=2.20.0 -> request==2.20.0 or a higher version
• httpx>=0.18.2 -> httpx==0.18.2 or a higher version

[rveachkc]

I'm not interested in making this change. In the past, pinning dependencies has made pymsteams difficult to work on or include in projects.

My strategy has been to keep the minimum version set to when it was validated and increment only when required to pass security vulnerability scans.

This is truly a pretty simple library, and the dependencies are pretty broadly used. It's my expectation that this will be used as part of a larger project, and pymsteams should be the flexible one.

I've applied the wontfix label, but will leave this open for discussion if you'd like.

[themanifold]

That's understandable. It just makes it hard to have pymsteams with pip-tools, as the most secure way of using it involves generating a hash of every dependency, and next nearest dependency (and so on) and it won't work if even one of the dependencies has a "loose" requirement, as I said in my first post. It's an ongoing issue that the pip-tools guys don't seem to want to budge on, so I'm now going to have to not use this secure mode.

To be clear, yours is not the only package that does not pin the packages exactly.

If you do decide to pin it, then you do get increased security - you won't pull in a compromised "updated version" of a package and reproducible builds.

[rveachkc]

While I do believe this is an important issue, I don't believe supply chain validation should be my responsibility as the maintainer of a project like this. I need to be focused on making the package work on a wide range of systems while keeping up with version minimums high enough to mitigate known threats. Anything further should be the responsibility of the downstream final project owner.

This is the first time I've heard of pip-tools, so I hope you understand my position on this, as pinning requirements has created problems for me in the past. This is especially true for a dependency like requests, which is often installed on the OS via .deb or .rpm.

I will mention that I've had quite a bit of luck using pipenv on other projects. It doesn't struggle with upstream dependency definitions like this. It can also be used to create deterministic builds as it stores hashes in a Pipfile.lock file.