124
Thank you IntelliJ (europe.pub)
submitted 2 months ago by 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.

you are viewing a single comment's thread
view the rest of the comments
[–] 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
    •
  • [–] [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
    •
  • [–] 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
  • [–] [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
    •
  • [–] 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
  • [–] 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
    •
  • [–] 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