I think it might be helpful to talk about some of the expected end results: e.g. what should the requirements.txt looks like, how can we advertise them, how do we use them in the ci, regardless of auto generating one from another, or perform consistency checking is more like a mechanical thing.
Because pip is still the status quo and should be our first class citizen, here is a strawman: - B0: Follow common practices(like pytorch) to specify loose dependencies - B1: When talking about installation and dev env, list both pip, conda and poetry without having to enoucrage one over another, we might want to put pip in the first place. >From B0, we might want the following files: - `requirements.txt`: common deps - Most should have no constraint at all - We can have minimum version constraint if necessary (e.g. `xgboost>=1.2.0`). - `requirements-extra.txt`: extra requirements (can have multiple, to simplify we can have ) - same as above, we can have a mininum version constraint. We should talk about whether or not maximum version constraint should be placed here. Per python ecosystem, seems a better practice for now is to only add maximum version constraint when there is a regression, and we should strive to remove as soon as it is fixed. Additionally, we can have the following constraint file - `ci-constraint.txt`: pinning the exact version that are needed in the CI, including dependency of dependencies if a regression occurs - We should only pinning things that are needed to be pinned as per current docker installation. We will use the txt files docker to generate the image to simplify the flow and make sure pip is the first class citizen. While it is true that a lock file might be more precise, we might still prefer the simplified flow per above discussion(lock does not cover everything and an equal constraint might be sufficient for most cases. --- [Visit Topic](https://discuss.tvm.apache.org/t/rfc-consolidating-tvm-python-dependencies/8329/9) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/418c79a0404a06f4155f2f55b17e054cd637cb651010996e7bd40058cd05b939).
