3 ms·

> Countless apps on PyPi are not on the Debian official repositories. So if you use them in your Python project, you can’t package the application for Debian an

by dozzie 10y ago

> Countless apps on PyPi are not on the Debian official repositories. So if you use them in your Python project, you can’t package the application for Debian anymore. OK, and how is it any surprise at all? What you need is to package those dependencies, too. Why would you expect it to be any different way? > What do the gurus in Debian say about this? > * Suppose your Python package has 10 dependencies that are not in the Debian official repository. In this case, you are suggested to package these 10 Python libraries first, submit them to the Debian official repository and then package your own app. > * If you are feeling too lazy [...] you are then suggested to refactor your code so that you only depend on the Python standard libraries and nothing else. And what is wrong with these approaches? Also, if you rely on ten libraries in your trivial application, you worked very hard for this outcome. pip, Ruby gems, and NPM make incorporating unnecessary dependencies too easy as they are at this point. Recall the left-pad farce. I am a sysadmin who also writes code, so I have seen the landscape from both sides. I take the packaging into an account before I write my first line. I try to keep dependencies reasonably small. All this because I've seen what it takes to maintain packages for a Linux distribution. And now we have you whining that Debian doesn't make their life hard to fullfil your ridiculous expectations as a random petty programmer.

gh1 10y ago
You have completely missed the point. A developer should not have to take packaging into account when writing their first line and adding dependencies. You are prepared to do it, good for you. But not every developer is like that. If you force your developers to do that, your packaging system is broken. Check out the Snap [0] and FlatPak [1] projects. They have emerged as a response to this problem. [0] http://snapcraft.io/ http://snapcraft.io/ [1] http://flatpak.org/ http://flatpak.org/
- dozzie 10y ago
  > You have completely missed the point. A developer should not have to take packaging into account when writing their first line and adding dependencies. I think I didn't miss. Author of the article wants his software in distribution. He should clearly take into account how distribution works and maybe constrained himself to the dependencies already in the distribution. Then again, he should take into account that the dependencies are in large part liabilities, and it's not only that the distribution may not have them packaged (left-pad again!). Maybe he just lacks experience that he happily uses whatever gets into his hands. > If you force your developers to [think of packaging], your packaging system is broken. It was working for over a decade without many issues (after "RPM hell" was more or less resolved), why would it suddenly stop working around five years ago? Around the same time version and tool churn popped out? And this Flatpak thing looks like "let's bundle all the OS libraries" (I may be wrong, but it's hard to come by a technical description on its website, so I'm forced to extrapolate). In this regard it's not far from static linking and all the bad things that it leads to. EDIT: The other one, snapcraft, says clearly that it bundles all the dependencies. Why did they choose Zip format for Linux/unix-only tool is beyond me, though.
- dozzie 10y ago
  One more thing: > You are prepared to do it, good for you. But not every developer is like that. They should. They work with those operating systems. They should know how they work, not avoid learning anything by using Bundler or VirtualEnv. I've seen too many so called "programmers" or "developers" who couldn't manage their way out of a paper bag once they did something stupid to their OS, like forcing installation of a broken RPM or accidentally setting 777 permissions on /tmp.

by dozzie 10y ago

gh1 10y ago

You have completely missed the point. A developer should not have to take packaging into account when writing their first line and adding dependencies. You are prepared to do it, good for you. But not every developer is like that. If you force your developers to do that, your packaging system is broken. Check out the Snap [0] and FlatPak [1] projects. They have emerged as a response to this problem. [0] http://snapcraft.io/ http://snapcraft.io/ [1] http://flatpak.org/ http://flatpak.org/

dozzie 10y ago
> You have completely missed the point. A developer should not have to take packaging into account when writing their first line and adding dependencies. I think I didn't miss. Author of the article wants his software in distribution. He should clearly take into account how distribution works and maybe constrained himself to the dependencies already in the distribution. Then again, he should take into account that the dependencies are in large part liabilities, and it's not only that the distribution may not have them packaged (left-pad again!). Maybe he just lacks experience that he happily uses whatever gets into his hands. > If you force your developers to [think of packaging], your packaging system is broken. It was working for over a decade without many issues (after "RPM hell" was more or less resolved), why would it suddenly stop working around five years ago? Around the same time version and tool churn popped out? And this Flatpak thing looks like "let's bundle all the OS libraries" (I may be wrong, but it's hard to come by a technical description on its website, so I'm forced to extrapolate). In this regard it's not far from static linking and all the bad things that it leads to. EDIT: The other one, snapcraft, says clearly that it bundles all the dependencies. Why did they choose Zip format for Linux/unix-only tool is beyond me, though.
dozzie 10y ago
One more thing: > You are prepared to do it, good for you. But not every developer is like that. They should. They work with those operating systems. They should know how they work, not avoid learning anything by using Bundler or VirtualEnv. I've seen too many so called "programmers" or "developers" who couldn't manage their way out of a paper bag once they did something stupid to their OS, like forcing installation of a broken RPM or accidentally setting 777 permissions on /tmp.