4 ms·

> Ironically using Docker I'd even dare to say that Docker _is_ the answer to the Python's packaging problems, and might have never taken off without that "kil

> Ironically using Docker I'd even dare to say that Docker _is_ the answer to the Python's packaging problems, and might have never taken off without that "killer app" that is the Python packaging sh*tshow.

hot_gril 4y ago
Yep. Any big Python repo is gonna have a Dockerfile. If something doesn't fix itself, users take matters into their own hands.
crabbone 4y ago
Docker is not the answer to any packaging problems because it's not a packaging tool. I have no idea how people don't understand this... oh wait! I'm talking to Python programmers! But... I'm not going to hold you in the dark: the reason and the major drive to have a packaging system is that you can define dependencies between packages s.t. users installing package can coordinate and install the stuff they need. Docker simply doesn't do that. You get images. They are completely independent. Whether any two images will work with each other is anyone's guess.
- groestl 4y ago
  Your post reminds me of the saying with the faster horses. Docker doesn't solve Python's packaging problems by being a better packaging system. It solves it by sidestepping the issue of users installing packages themselves, and shipping the disk of the one machine where it once worked. It's a bad linker. (not a fan of the condescending tone in your post, btw)
  - crabbone 4y ago
    > It solves it by sidestepping the issue Lol. It doesn't. How are you going to create Docker images? Run more Dockers inside Docker? And then Dockers all the way down? You still need to install the packages... just while creating an image. Makes absolutely no difference whether you do it inside or outside, you still need something that can install and coordinate packages. Docker is simply irrelevant to this problem.
    - groestl 4y ago
      > How are you going to create Docker images? Once. On a build server. Or a dev's workstation who had the time to fiddle with all the breakage that is python envs. This absolutely does sidestep the issue of distributing Python packages to your users. We're talking about different problems here. You are talking about library dependencies for devs (and I understand that I'm a bit off topic for this thread)
      - crabbone 4y ago
        > Once. On a build server. I didn't ask where, I asked how. How will you know what packages do you need to install? Are you going to go on pypi.org, download them one by one, unzip, look for requirements, then go to pypi.org again, download more, and so on, until you have enough packages and have figured out all the requirements? If so, I have very bad news for you: your single installation might take weeks, possibly months, or might in fact be so slow it will never end as new packages will be published faster than you can identify the version you need. > This absolutely does sidestep the issue of distributing Python packages to your users. No it doesn't... OMG. You cannot be serious? Do you really search and solve dependency problems w/o using any dedicated software? Like in your head? Or with pen and paper? For any non-trivial project the number of combinations you have to try before you find the one that works will be astronomical... > We're talking about different problems here. Nah. You just don't understand the problem. It's similar, but not the same.
        groestl 4y ago
        You have a very abrasive style of dialog, combined with an unwillingness to consider alternative POVs in your discussion, bordering on trolling. I like discussion, but I don't enjoy this. With that, I will disengage now.
        crabbone 4y ago
        You don't have an alternative point of view. You don't have a point of view, because, again, you don't understand something very basic about this subject.
331c8c71 4y ago
It's only a workaround unless the python env in the resulting docker is reproducible for all practical purposes. Otherwise the generated images become precious artifacts you can't loose - there is a risk you gonna get problems if you re-build the image now instead of reusing the working one built X years/months ago.
- groestl 4y ago
  Fully agree. I didn't say it's a good answer ;)

hot_gril 4y ago

Yep. Any big Python repo is gonna have a Dockerfile. If something doesn't fix itself, users take matters into their own hands.

crabbone 4y ago

Docker is not the answer to any packaging problems because it's not a packaging tool. I have no idea how people don't understand this... oh wait! I'm talking to Python programmers! But... I'm not going to hold you in the dark: the reason and the major drive to have a packaging system is that you can define dependencies between packages s.t. users installing package can coordinate and install the stuff they need. Docker simply doesn't do that. You get images. They are completely independent. Whether any two images will work with each other is anyone's guess.

groestl 4y ago
Your post reminds me of the saying with the faster horses. Docker doesn't solve Python's packaging problems by being a better packaging system. It solves it by sidestepping the issue of users installing packages themselves, and shipping the disk of the one machine where it once worked. It's a bad linker. (not a fan of the condescending tone in your post, btw)
- crabbone 4y ago
  > It solves it by sidestepping the issue Lol. It doesn't. How are you going to create Docker images? Run more Dockers inside Docker? And then Dockers all the way down? You still need to install the packages... just while creating an image. Makes absolutely no difference whether you do it inside or outside, you still need something that can install and coordinate packages. Docker is simply irrelevant to this problem.
  - groestl 4y ago
    > How are you going to create Docker images? Once. On a build server. Or a dev's workstation who had the time to fiddle with all the breakage that is python envs. This absolutely does sidestep the issue of distributing Python packages to your users. We're talking about different problems here. You are talking about library dependencies for devs (and I understand that I'm a bit off topic for this thread)
    - crabbone 4y ago
      > Once. On a build server. I didn't ask where, I asked how. How will you know what packages do you need to install? Are you going to go on pypi.org, download them one by one, unzip, look for requirements, then go to pypi.org again, download more, and so on, until you have enough packages and have figured out all the requirements? If so, I have very bad news for you: your single installation might take weeks, possibly months, or might in fact be so slow it will never end as new packages will be published faster than you can identify the version you need. > This absolutely does sidestep the issue of distributing Python packages to your users. No it doesn't... OMG. You cannot be serious? Do you really search and solve dependency problems w/o using any dedicated software? Like in your head? Or with pen and paper? For any non-trivial project the number of combinations you have to try before you find the one that works will be astronomical... > We're talking about different problems here. Nah. You just don't understand the problem. It's similar, but not the same.
      - groestl 4y ago
        You have a very abrasive style of dialog, combined with an unwillingness to consider alternative POVs in your discussion, bordering on trolling. I like discussion, but I don't enjoy this. With that, I will disengage now.
        crabbone 4y ago
        You don't have an alternative point of view. You don't have a point of view, because, again, you don't understand something very basic about this subject.

331c8c71 4y ago

It's only a workaround unless the python env in the resulting docker is reproducible for all practical purposes. Otherwise the generated images become precious artifacts you can't loose - there is a risk you gonna get problems if you re-build the image now instead of reusing the working one built X years/months ago.

groestl 4y ago
Fully agree. I didn't say it's a good answer ;)