3 ms·

So in a deb I can run "pip install foo"? I have this idea that deb is more file-oriented. Never looked into it properly.

yebyen 9y ago
Take a deb and run "ar -xv" on it You will get out a control.tar.gz, data.tar.gz, and debian-binary file which is a text document with a version for something in it. (Not the package version. Maybe DPKG api version.) Now, just look at how simple this structure is and marvel at how quickly you can demystify debs! If you wanted to run "pip install" you could do it in the postinst, a part of control.tar.gz, but this is not the traditional way in a deb. No reason you couldn't do it. Traditionally you should list those pip dependencies as dependencies in control and let debuild or your preferred deb building tool pack it up this way for you, then they can be frozen and will be reproducible through only the package mirrors. (The dependencies are listed as dependencies, and they are also packaged into debs.) I am looking at my heroku_3.99.4_all.deb that I happened to find first, and data.tar.gz contains a single empty directory usr/local/heroku/ for the place that postinst will dump things into (postinst does a wget to some path at https://cli-assets.heroku.com https://cli-assets.heroku.com, and moves a few things around after that.) IMHO this is a terrible deb, because if heroku goes away it will completely bomb out and fail to install. (Then again if heroku does go away, what do you need the heroku client for exactly?) Your suggestion of doing pip install has the same problem, but what's worse? I am a rubyist and I would never question whether you should use bundler to manage your dependencies. Absolutely you should, the package versions in stable distros are atrocious and usually horrifically outdated, and you almost certainly don't want to use anything but a stable distro in production. So, to recap, yes you can but it is not usually done this way.
- bboreham 9y ago
  > Your suggestion of doing pip install has the same problem Recalling that I am speaking in a Dockerfile context, no it doesn't. The 'pip install' runs once, on my machine when I create the Docker image. Thank you for the detailed explanation. You have clarified that "just build a deb" is an entirely different exercise.
  - yebyen 9y ago
    Absolutely. The pip install command is perfect for a Dockerfile where your entire filesystem state is captured and snapshotted. It is a poor way to build a deb, where dependencies are supposed to be explicit and user-pinnable. That's all! :) Thanks for writing back. (In the Heroku deb example, you can't even guarantee that you are going to get the version back from the server that the deb file says it contains. That's probably by design, because Heroku does not intend to break backwards compatibility with new releases of the client, and wants to force upgrades so that they know that you have the latest version of the client at all times.)

yebyen 9y ago

Take a deb and run "ar -xv" on it You will get out a control.tar.gz, data.tar.gz, and debian-binary file which is a text document with a version for something in it. (Not the package version. Maybe DPKG api version.) Now, just look at how simple this structure is and marvel at how quickly you can demystify debs! If you wanted to run "pip install" you could do it in the postinst, a part of control.tar.gz, but this is not the traditional way in a deb. No reason you couldn't do it. Traditionally you should list those pip dependencies as dependencies in control and let debuild or your preferred deb building tool pack it up this way for you, then they can be frozen and will be reproducible through only the package mirrors. (The dependencies are listed as dependencies, and they are also packaged into debs.) I am looking at my heroku_3.99.4_all.deb that I happened to find first, and data.tar.gz contains a single empty directory usr/local/heroku/ for the place that postinst will dump things into (postinst does a wget to some path at https://cli-assets.heroku.com https://cli-assets.heroku.com, and moves a few things around after that.) IMHO this is a terrible deb, because if heroku goes away it will completely bomb out and fail to install. (Then again if heroku does go away, what do you need the heroku client for exactly?) Your suggestion of doing pip install has the same problem, but what's worse? I am a rubyist and I would never question whether you should use bundler to manage your dependencies. Absolutely you should, the package versions in stable distros are atrocious and usually horrifically outdated, and you almost certainly don't want to use anything but a stable distro in production. So, to recap, yes you can but it is not usually done this way.

bboreham 9y ago
> Your suggestion of doing pip install has the same problem Recalling that I am speaking in a Dockerfile context, no it doesn't. The 'pip install' runs once, on my machine when I create the Docker image. Thank you for the detailed explanation. You have clarified that "just build a deb" is an entirely different exercise.
- yebyen 9y ago
  Absolutely. The pip install command is perfect for a Dockerfile where your entire filesystem state is captured and snapshotted. It is a poor way to build a deb, where dependencies are supposed to be explicit and user-pinnable. That's all! :) Thanks for writing back. (In the Heroku deb example, you can't even guarantee that you are going to get the version back from the server that the deb file says it contains. That's probably by design, because Heroku does not intend to break backwards compatibility with new releases of the client, and wants to force upgrades so that they know that you have the latest version of the client at all times.)