▲ 124 ▼ Thank you IntelliJ (europe.pub) submitted 2 months ago by Mickkc@lmy.ndu.wtf to c/programmerhumor@lemmy.ml 24 comments fedilink hide all child comments I was just editing my Dockerfile and suddenly IntelliJ showed me the message "No" without any context.
[–] eager_eagle@lemmy.world 38 points 2 months ago (23 children) It's right, you shouldn't be using requirements.txt in 2026 permalink fedilink source hideshow 23 child comments replies: [–] Mickkc@lmy.ndu.wtf [S] 14 points 2 months ago (22 children) What should I use instead? pyproject.toml? I am pretty new to Python so I'm not very familiar with the ecosystem yet... permalink fedilink source parent hideshow 22 child comments replies: [–] aBundleOfFerrets@sh.itjust.works 27 points 2 months ago (2 children) It’s not important what you should be doing, just that requirements.txt ‘No’ permalink fedilink source parent hideshow 2 child comments replies: [–] Mickkc@lmy.ndu.wtf [S] 23 points 2 months ago (1 child) permalink fedilink source parent hideshow 1 child comment replies: [–] eldavi@lemmy.ml 5 points 2 months ago* I'm a dinosaur still using vim but I'd consider switching IDE's if they had this much snarky behavior. Lol permalink fedilink source parent [–] eager_eagle@lemmy.world 20 points 2 months ago (8 children) yes, and give uv a try https://docs.astral.sh/uv/getting-started/installation/ uv init + project management commands uv add, uv remove, uv sync, uv run my_spaghetti.py, ... you probably don't need pip or uv pip commands and here's how to use it in docker https://docs.astral.sh/uv/guides/integration/docker/ permalink fedilink source parent hideshow 8 child comments replies: [–] BlameTheAntifa@lemmy.world 7 points 2 months ago (6 children) UV’s parent company was purchased by OpenAI. I recommend Poetry instead. permalink fedilink source parent hideshow 6 child comments replies: [–] eager_eagle@lemmy.world 13 points 2 months ago (4 children) I used poetry for years before uv, but uv is just a better tool. If openai enshittifies it, I have no doubt it'll be forked instantly. permalink fedilink source parent hideshow 4 child comments replies: [–] BlameTheAntifa@lemmy.world 4 points 2 months ago (3 children) Think about what they get by controlling a popular package manager. Think about what you give them. You will not feel the consequences directly. permalink fedilink source parent hideshow 3 child comments replies: [–] eager_eagle@lemmy.world 11 points 2 months ago (1 child) what I do feel is how slow poetry is for resolving dependencies permalink fedilink source parent hideshow 1 child comment replies: [–] NotSteve_@lemmy.ca 5 points 2 months ago Yeah I used to be a huge advocate for Poetry and convinced my previous company to switch to it but it's painfully slow when compared to UV so I can't go back permalink fedilink source parent [–] HetareKing@piefed.social 8 points 2 months ago Doesn't uv just use PyPI for its packages (i.e. it's not talking to any servers owned by them)? There's the possibility of hijinks on the client side, of course, but it would be hard to do without anyone noticing and causing a huge stink about it. I'd say the more worrying aspects of uv is the use of AI in its development even before OpenAI bought them out and what's going to happen to it after OpenAI eventually goes under. permalink fedilink source parent [–] jtrek@startrek.website 9 points 2 months ago Fuck. Fuck all this AI slop. permalink fedilink source parent [–] Mickkc@lmy.ndu.wtf [S] 4 points 2 months ago* (last edited 2 months ago) That looks really convenient, especially when installing and switching Python versions. I'll keep that in mind. Thanks! permalink fedilink source parent [–] bamboo@lemmy.blahaj.zone 5 points 2 months ago (6 children) Curious what others have to say, but my go to is to have a requirements.in with direct packages I need for the project, and then run pip-compile to generate all the dependencies with their exact version at the time so that deployments are repeatable. This works well for deployment, but if I were writing a library for others to use, I think you put the direct dependencies in setup.py permalink fedilink source parent hideshow 6 child comments replies: [–] Mickkc@lmy.ndu.wtf [S] 2 points 2 months ago (3 children) I don't quite understand that. I did some research, and I read that the requirements.txt is somehow generated from requirements.in. But what is the difference between the two files then? Could you give me an example of what a requirements.in file would look like? Thank you! permalink fedilink source parent hideshow 3 child comments replies: [–] scrion@lemmy.world 5 points 2 months ago Please use a pyproject.toml file for both project setup and dependency management. It actually is standardized now in PEPs. uv is a great tool, now comes with a build tool as well. It has become a de-facto standard. permalink fedilink source parent [–] Mickkc@lmy.ndu.wtf [S] 2 points 2 months ago* (1 child) Ohhh now I get it. It's basically like package.json and package-lock.json in node, but for Python. It's a bit strange to me that this isn't the default in Python... permalink fedilink source parent hideshow 1 child comment replies: [–] bamboo@lemmy.blahaj.zone 3 points 2 months ago Yes exactly, like if I know my app needs the requests library, I will just put that in requirements.in but after compile requirements.txt will include the exact version of requests and every version of each dependency. So that every time pip install is run, all dependencies are always the same despite what happens upstream permalink fedilink source parent [–] AnnaFrankfurter@lemmy.ml 1 point 2 months ago (1 child) Why not put all dependencies and all with versions. I do that permalink fedilink source parent hideshow 1 child comment replies: [–] bamboo@lemmy.blahaj.zone 4 points 2 months ago Well if the requirements.txt is pinned to a specific version of a dependency of a dependency, you might not know or really care why that's set. But then this becomes a nightmare and dependency hell laterif you want a newer version of some package, and that newer version requires a bunch of newer packages and loses the others. At that point you probably will toss your old file and start a new one from scratch piecing together all the requirements with like pip freeze in a new virtual environment. Sure you could omit the versions, but then everytime you deploy, you don't know what you're going to get and a deployment today would be very different next week with a whole bunch of different versions of dependencies. permalink fedilink source parent [–] assaultpotato@sh.itjust.works 5 points 2 months ago* uv + pyproject.toml. and any other answers like "poetry" are objectively wrong permalink fedilink source parent [–] assaultpotato@sh.itjust.works 4 points 2 months ago also ty + ruff for linting and type checking, basically if Astral makes it its probably worth using. permalink fedilink source parent [–] pineapple@lemmy.ml 1 point 2 months ago uv and pyproject.toml is so much easier than pip and requirements.txt permalink fedilink source parent
[–] Mickkc@lmy.ndu.wtf [S] 14 points 2 months ago (22 children) What should I use instead? pyproject.toml? I am pretty new to Python so I'm not very familiar with the ecosystem yet... permalink fedilink source parent hideshow 22 child comments replies: [–] aBundleOfFerrets@sh.itjust.works 27 points 2 months ago (2 children) It’s not important what you should be doing, just that requirements.txt ‘No’ permalink fedilink source parent hideshow 2 child comments replies: [–] Mickkc@lmy.ndu.wtf [S] 23 points 2 months ago (1 child) permalink fedilink source parent hideshow 1 child comment replies: [–] eldavi@lemmy.ml 5 points 2 months ago* I'm a dinosaur still using vim but I'd consider switching IDE's if they had this much snarky behavior. Lol permalink fedilink source parent [–] eager_eagle@lemmy.world 20 points 2 months ago (8 children) yes, and give uv a try https://docs.astral.sh/uv/getting-started/installation/ uv init + project management commands uv add, uv remove, uv sync, uv run my_spaghetti.py, ... you probably don't need pip or uv pip commands and here's how to use it in docker https://docs.astral.sh/uv/guides/integration/docker/ permalink fedilink source parent hideshow 8 child comments replies: [–] BlameTheAntifa@lemmy.world 7 points 2 months ago (6 children) UV’s parent company was purchased by OpenAI. I recommend Poetry instead. permalink fedilink source parent hideshow 6 child comments replies: [–] eager_eagle@lemmy.world 13 points 2 months ago (4 children) I used poetry for years before uv, but uv is just a better tool. If openai enshittifies it, I have no doubt it'll be forked instantly. permalink fedilink source parent hideshow 4 child comments replies: [–] BlameTheAntifa@lemmy.world 4 points 2 months ago (3 children) Think about what they get by controlling a popular package manager. Think about what you give them. You will not feel the consequences directly. permalink fedilink source parent hideshow 3 child comments replies: [–] eager_eagle@lemmy.world 11 points 2 months ago (1 child) what I do feel is how slow poetry is for resolving dependencies permalink fedilink source parent hideshow 1 child comment replies: [–] NotSteve_@lemmy.ca 5 points 2 months ago Yeah I used to be a huge advocate for Poetry and convinced my previous company to switch to it but it's painfully slow when compared to UV so I can't go back permalink fedilink source parent [–] HetareKing@piefed.social 8 points 2 months ago Doesn't uv just use PyPI for its packages (i.e. it's not talking to any servers owned by them)? There's the possibility of hijinks on the client side, of course, but it would be hard to do without anyone noticing and causing a huge stink about it. I'd say the more worrying aspects of uv is the use of AI in its development even before OpenAI bought them out and what's going to happen to it after OpenAI eventually goes under. permalink fedilink source parent [–] jtrek@startrek.website 9 points 2 months ago Fuck. Fuck all this AI slop. permalink fedilink source parent [–] Mickkc@lmy.ndu.wtf [S] 4 points 2 months ago* (last edited 2 months ago) That looks really convenient, especially when installing and switching Python versions. I'll keep that in mind. Thanks! permalink fedilink source parent [–] bamboo@lemmy.blahaj.zone 5 points 2 months ago (6 children) Curious what others have to say, but my go to is to have a requirements.in with direct packages I need for the project, and then run pip-compile to generate all the dependencies with their exact version at the time so that deployments are repeatable. This works well for deployment, but if I were writing a library for others to use, I think you put the direct dependencies in setup.py permalink fedilink source parent hideshow 6 child comments replies: [–] Mickkc@lmy.ndu.wtf [S] 2 points 2 months ago (3 children) I don't quite understand that. I did some research, and I read that the requirements.txt is somehow generated from requirements.in. But what is the difference between the two files then? Could you give me an example of what a requirements.in file would look like? Thank you! permalink fedilink source parent hideshow 3 child comments replies: [–] scrion@lemmy.world 5 points 2 months ago Please use a pyproject.toml file for both project setup and dependency management. It actually is standardized now in PEPs. uv is a great tool, now comes with a build tool as well. It has become a de-facto standard. permalink fedilink source parent [–] Mickkc@lmy.ndu.wtf [S] 2 points 2 months ago* (1 child) Ohhh now I get it. It's basically like package.json and package-lock.json in node, but for Python. It's a bit strange to me that this isn't the default in Python... permalink fedilink source parent hideshow 1 child comment replies: [–] bamboo@lemmy.blahaj.zone 3 points 2 months ago Yes exactly, like if I know my app needs the requests library, I will just put that in requirements.in but after compile requirements.txt will include the exact version of requests and every version of each dependency. So that every time pip install is run, all dependencies are always the same despite what happens upstream permalink fedilink source parent [–] AnnaFrankfurter@lemmy.ml 1 point 2 months ago (1 child) Why not put all dependencies and all with versions. I do that permalink fedilink source parent hideshow 1 child comment replies: [–] bamboo@lemmy.blahaj.zone 4 points 2 months ago Well if the requirements.txt is pinned to a specific version of a dependency of a dependency, you might not know or really care why that's set. But then this becomes a nightmare and dependency hell laterif you want a newer version of some package, and that newer version requires a bunch of newer packages and loses the others. At that point you probably will toss your old file and start a new one from scratch piecing together all the requirements with like pip freeze in a new virtual environment. Sure you could omit the versions, but then everytime you deploy, you don't know what you're going to get and a deployment today would be very different next week with a whole bunch of different versions of dependencies. permalink fedilink source parent [–] assaultpotato@sh.itjust.works 5 points 2 months ago* uv + pyproject.toml. and any other answers like "poetry" are objectively wrong permalink fedilink source parent [–] assaultpotato@sh.itjust.works 4 points 2 months ago also ty + ruff for linting and type checking, basically if Astral makes it its probably worth using. permalink fedilink source parent [–] pineapple@lemmy.ml 1 point 2 months ago uv and pyproject.toml is so much easier than pip and requirements.txt permalink fedilink source parent
[–] aBundleOfFerrets@sh.itjust.works 27 points 2 months ago (2 children) It’s not important what you should be doing, just that requirements.txt ‘No’ permalink fedilink source parent hideshow 2 child comments replies: [–] Mickkc@lmy.ndu.wtf [S] 23 points 2 months ago (1 child) permalink fedilink source parent hideshow 1 child comment replies: [–] eldavi@lemmy.ml 5 points 2 months ago* I'm a dinosaur still using vim but I'd consider switching IDE's if they had this much snarky behavior. Lol permalink fedilink source parent
[–] Mickkc@lmy.ndu.wtf [S] 23 points 2 months ago (1 child) permalink fedilink source parent hideshow 1 child comment replies: [–] eldavi@lemmy.ml 5 points 2 months ago* I'm a dinosaur still using vim but I'd consider switching IDE's if they had this much snarky behavior. Lol permalink fedilink source parent
[–] eldavi@lemmy.ml 5 points 2 months ago* I'm a dinosaur still using vim but I'd consider switching IDE's if they had this much snarky behavior. Lol permalink fedilink source parent
[–] eager_eagle@lemmy.world 20 points 2 months ago (8 children) yes, and give uv a try https://docs.astral.sh/uv/getting-started/installation/ uv init + project management commands uv add, uv remove, uv sync, uv run my_spaghetti.py, ... you probably don't need pip or uv pip commands and here's how to use it in docker https://docs.astral.sh/uv/guides/integration/docker/ permalink fedilink source parent hideshow 8 child comments replies: [–] BlameTheAntifa@lemmy.world 7 points 2 months ago (6 children) UV’s parent company was purchased by OpenAI. I recommend Poetry instead. permalink fedilink source parent hideshow 6 child comments replies: [–] eager_eagle@lemmy.world 13 points 2 months ago (4 children) I used poetry for years before uv, but uv is just a better tool. If openai enshittifies it, I have no doubt it'll be forked instantly. permalink fedilink source parent hideshow 4 child comments replies: [–] BlameTheAntifa@lemmy.world 4 points 2 months ago (3 children) Think about what they get by controlling a popular package manager. Think about what you give them. You will not feel the consequences directly. permalink fedilink source parent hideshow 3 child comments replies: [–] eager_eagle@lemmy.world 11 points 2 months ago (1 child) what I do feel is how slow poetry is for resolving dependencies permalink fedilink source parent hideshow 1 child comment replies: [–] NotSteve_@lemmy.ca 5 points 2 months ago Yeah I used to be a huge advocate for Poetry and convinced my previous company to switch to it but it's painfully slow when compared to UV so I can't go back permalink fedilink source parent [–] HetareKing@piefed.social 8 points 2 months ago Doesn't uv just use PyPI for its packages (i.e. it's not talking to any servers owned by them)? There's the possibility of hijinks on the client side, of course, but it would be hard to do without anyone noticing and causing a huge stink about it. I'd say the more worrying aspects of uv is the use of AI in its development even before OpenAI bought them out and what's going to happen to it after OpenAI eventually goes under. permalink fedilink source parent [–] jtrek@startrek.website 9 points 2 months ago Fuck. Fuck all this AI slop. permalink fedilink source parent [–] Mickkc@lmy.ndu.wtf [S] 4 points 2 months ago* (last edited 2 months ago) That looks really convenient, especially when installing and switching Python versions. I'll keep that in mind. Thanks! permalink fedilink source parent
[–] BlameTheAntifa@lemmy.world 7 points 2 months ago (6 children) UV’s parent company was purchased by OpenAI. I recommend Poetry instead. permalink fedilink source parent hideshow 6 child comments replies: [–] eager_eagle@lemmy.world 13 points 2 months ago (4 children) I used poetry for years before uv, but uv is just a better tool. If openai enshittifies it, I have no doubt it'll be forked instantly. permalink fedilink source parent hideshow 4 child comments replies: [–] BlameTheAntifa@lemmy.world 4 points 2 months ago (3 children) Think about what they get by controlling a popular package manager. Think about what you give them. You will not feel the consequences directly. permalink fedilink source parent hideshow 3 child comments replies: [–] eager_eagle@lemmy.world 11 points 2 months ago (1 child) what I do feel is how slow poetry is for resolving dependencies permalink fedilink source parent hideshow 1 child comment replies: [–] NotSteve_@lemmy.ca 5 points 2 months ago Yeah I used to be a huge advocate for Poetry and convinced my previous company to switch to it but it's painfully slow when compared to UV so I can't go back permalink fedilink source parent [–] HetareKing@piefed.social 8 points 2 months ago Doesn't uv just use PyPI for its packages (i.e. it's not talking to any servers owned by them)? There's the possibility of hijinks on the client side, of course, but it would be hard to do without anyone noticing and causing a huge stink about it. I'd say the more worrying aspects of uv is the use of AI in its development even before OpenAI bought them out and what's going to happen to it after OpenAI eventually goes under. permalink fedilink source parent [–] jtrek@startrek.website 9 points 2 months ago Fuck. Fuck all this AI slop. permalink fedilink source parent
[–] eager_eagle@lemmy.world 13 points 2 months ago (4 children) I used poetry for years before uv, but uv is just a better tool. If openai enshittifies it, I have no doubt it'll be forked instantly. permalink fedilink source parent hideshow 4 child comments replies: [–] BlameTheAntifa@lemmy.world 4 points 2 months ago (3 children) Think about what they get by controlling a popular package manager. Think about what you give them. You will not feel the consequences directly. permalink fedilink source parent hideshow 3 child comments replies: [–] eager_eagle@lemmy.world 11 points 2 months ago (1 child) what I do feel is how slow poetry is for resolving dependencies permalink fedilink source parent hideshow 1 child comment replies: [–] NotSteve_@lemmy.ca 5 points 2 months ago Yeah I used to be a huge advocate for Poetry and convinced my previous company to switch to it but it's painfully slow when compared to UV so I can't go back permalink fedilink source parent [–] HetareKing@piefed.social 8 points 2 months ago Doesn't uv just use PyPI for its packages (i.e. it's not talking to any servers owned by them)? There's the possibility of hijinks on the client side, of course, but it would be hard to do without anyone noticing and causing a huge stink about it. I'd say the more worrying aspects of uv is the use of AI in its development even before OpenAI bought them out and what's going to happen to it after OpenAI eventually goes under. permalink fedilink source parent
[–] BlameTheAntifa@lemmy.world 4 points 2 months ago (3 children) Think about what they get by controlling a popular package manager. Think about what you give them. You will not feel the consequences directly. permalink fedilink source parent hideshow 3 child comments replies: [–] eager_eagle@lemmy.world 11 points 2 months ago (1 child) what I do feel is how slow poetry is for resolving dependencies permalink fedilink source parent hideshow 1 child comment replies: [–] NotSteve_@lemmy.ca 5 points 2 months ago Yeah I used to be a huge advocate for Poetry and convinced my previous company to switch to it but it's painfully slow when compared to UV so I can't go back permalink fedilink source parent [–] HetareKing@piefed.social 8 points 2 months ago Doesn't uv just use PyPI for its packages (i.e. it's not talking to any servers owned by them)? There's the possibility of hijinks on the client side, of course, but it would be hard to do without anyone noticing and causing a huge stink about it. I'd say the more worrying aspects of uv is the use of AI in its development even before OpenAI bought them out and what's going to happen to it after OpenAI eventually goes under. permalink fedilink source parent
[–] eager_eagle@lemmy.world 11 points 2 months ago (1 child) what I do feel is how slow poetry is for resolving dependencies permalink fedilink source parent hideshow 1 child comment replies: [–] NotSteve_@lemmy.ca 5 points 2 months ago Yeah I used to be a huge advocate for Poetry and convinced my previous company to switch to it but it's painfully slow when compared to UV so I can't go back permalink fedilink source parent
[–] NotSteve_@lemmy.ca 5 points 2 months ago Yeah I used to be a huge advocate for Poetry and convinced my previous company to switch to it but it's painfully slow when compared to UV so I can't go back permalink fedilink source parent
[–] HetareKing@piefed.social 8 points 2 months ago Doesn't uv just use PyPI for its packages (i.e. it's not talking to any servers owned by them)? There's the possibility of hijinks on the client side, of course, but it would be hard to do without anyone noticing and causing a huge stink about it. I'd say the more worrying aspects of uv is the use of AI in its development even before OpenAI bought them out and what's going to happen to it after OpenAI eventually goes under. permalink fedilink source parent
[–] jtrek@startrek.website 9 points 2 months ago Fuck. Fuck all this AI slop. permalink fedilink source parent
[–] Mickkc@lmy.ndu.wtf [S] 4 points 2 months ago* (last edited 2 months ago) That looks really convenient, especially when installing and switching Python versions. I'll keep that in mind. Thanks! permalink fedilink source parent
[–] bamboo@lemmy.blahaj.zone 5 points 2 months ago (6 children) Curious what others have to say, but my go to is to have a requirements.in with direct packages I need for the project, and then run pip-compile to generate all the dependencies with their exact version at the time so that deployments are repeatable. This works well for deployment, but if I were writing a library for others to use, I think you put the direct dependencies in setup.py permalink fedilink source parent hideshow 6 child comments replies: [–] Mickkc@lmy.ndu.wtf [S] 2 points 2 months ago (3 children) I don't quite understand that. I did some research, and I read that the requirements.txt is somehow generated from requirements.in. But what is the difference between the two files then? Could you give me an example of what a requirements.in file would look like? Thank you! permalink fedilink source parent hideshow 3 child comments replies: [–] scrion@lemmy.world 5 points 2 months ago Please use a pyproject.toml file for both project setup and dependency management. It actually is standardized now in PEPs. uv is a great tool, now comes with a build tool as well. It has become a de-facto standard. permalink fedilink source parent [–] Mickkc@lmy.ndu.wtf [S] 2 points 2 months ago* (1 child) Ohhh now I get it. It's basically like package.json and package-lock.json in node, but for Python. It's a bit strange to me that this isn't the default in Python... permalink fedilink source parent hideshow 1 child comment replies: [–] bamboo@lemmy.blahaj.zone 3 points 2 months ago Yes exactly, like if I know my app needs the requests library, I will just put that in requirements.in but after compile requirements.txt will include the exact version of requests and every version of each dependency. So that every time pip install is run, all dependencies are always the same despite what happens upstream permalink fedilink source parent [–] AnnaFrankfurter@lemmy.ml 1 point 2 months ago (1 child) Why not put all dependencies and all with versions. I do that permalink fedilink source parent hideshow 1 child comment replies: [–] bamboo@lemmy.blahaj.zone 4 points 2 months ago Well if the requirements.txt is pinned to a specific version of a dependency of a dependency, you might not know or really care why that's set. But then this becomes a nightmare and dependency hell laterif you want a newer version of some package, and that newer version requires a bunch of newer packages and loses the others. At that point you probably will toss your old file and start a new one from scratch piecing together all the requirements with like pip freeze in a new virtual environment. Sure you could omit the versions, but then everytime you deploy, you don't know what you're going to get and a deployment today would be very different next week with a whole bunch of different versions of dependencies. permalink fedilink source parent
[–] Mickkc@lmy.ndu.wtf [S] 2 points 2 months ago (3 children) I don't quite understand that. I did some research, and I read that the requirements.txt is somehow generated from requirements.in. But what is the difference between the two files then? Could you give me an example of what a requirements.in file would look like? Thank you! permalink fedilink source parent hideshow 3 child comments replies: [–] scrion@lemmy.world 5 points 2 months ago Please use a pyproject.toml file for both project setup and dependency management. It actually is standardized now in PEPs. uv is a great tool, now comes with a build tool as well. It has become a de-facto standard. permalink fedilink source parent [–] Mickkc@lmy.ndu.wtf [S] 2 points 2 months ago* (1 child) Ohhh now I get it. It's basically like package.json and package-lock.json in node, but for Python. It's a bit strange to me that this isn't the default in Python... permalink fedilink source parent hideshow 1 child comment replies: [–] bamboo@lemmy.blahaj.zone 3 points 2 months ago Yes exactly, like if I know my app needs the requests library, I will just put that in requirements.in but after compile requirements.txt will include the exact version of requests and every version of each dependency. So that every time pip install is run, all dependencies are always the same despite what happens upstream permalink fedilink source parent
[–] scrion@lemmy.world 5 points 2 months ago Please use a pyproject.toml file for both project setup and dependency management. It actually is standardized now in PEPs. uv is a great tool, now comes with a build tool as well. It has become a de-facto standard. permalink fedilink source parent
[–] Mickkc@lmy.ndu.wtf [S] 2 points 2 months ago* (1 child) Ohhh now I get it. It's basically like package.json and package-lock.json in node, but for Python. It's a bit strange to me that this isn't the default in Python... permalink fedilink source parent hideshow 1 child comment replies: [–] bamboo@lemmy.blahaj.zone 3 points 2 months ago Yes exactly, like if I know my app needs the requests library, I will just put that in requirements.in but after compile requirements.txt will include the exact version of requests and every version of each dependency. So that every time pip install is run, all dependencies are always the same despite what happens upstream permalink fedilink source parent
[–] bamboo@lemmy.blahaj.zone 3 points 2 months ago Yes exactly, like if I know my app needs the requests library, I will just put that in requirements.in but after compile requirements.txt will include the exact version of requests and every version of each dependency. So that every time pip install is run, all dependencies are always the same despite what happens upstream permalink fedilink source parent
[–] AnnaFrankfurter@lemmy.ml 1 point 2 months ago (1 child) Why not put all dependencies and all with versions. I do that permalink fedilink source parent hideshow 1 child comment replies: [–] bamboo@lemmy.blahaj.zone 4 points 2 months ago Well if the requirements.txt is pinned to a specific version of a dependency of a dependency, you might not know or really care why that's set. But then this becomes a nightmare and dependency hell laterif you want a newer version of some package, and that newer version requires a bunch of newer packages and loses the others. At that point you probably will toss your old file and start a new one from scratch piecing together all the requirements with like pip freeze in a new virtual environment. Sure you could omit the versions, but then everytime you deploy, you don't know what you're going to get and a deployment today would be very different next week with a whole bunch of different versions of dependencies. permalink fedilink source parent
[–] bamboo@lemmy.blahaj.zone 4 points 2 months ago Well if the requirements.txt is pinned to a specific version of a dependency of a dependency, you might not know or really care why that's set. But then this becomes a nightmare and dependency hell laterif you want a newer version of some package, and that newer version requires a bunch of newer packages and loses the others. At that point you probably will toss your old file and start a new one from scratch piecing together all the requirements with like pip freeze in a new virtual environment. Sure you could omit the versions, but then everytime you deploy, you don't know what you're going to get and a deployment today would be very different next week with a whole bunch of different versions of dependencies. permalink fedilink source parent
[–] assaultpotato@sh.itjust.works 5 points 2 months ago* uv + pyproject.toml. and any other answers like "poetry" are objectively wrong permalink fedilink source parent
[–] assaultpotato@sh.itjust.works 4 points 2 months ago also ty + ruff for linting and type checking, basically if Astral makes it its probably worth using. permalink fedilink source parent
[–] pineapple@lemmy.ml 1 point 2 months ago uv and pyproject.toml is so much easier than pip and requirements.txt permalink fedilink source parent
all 24 comments