4 ms·
I wish they didn't track Python and Go packages in their repositories--especially with Python. These languages already have their own package managers, and thi
by hello_computer 3y ago
I wish they didn't track Python and Go packages in their repositories--especially with Python. These languages already have their own package managers, and this creates so many different problems when user calls to pip/go-install have collisions with whatever root installed via apt-get.
- trashburger 3y agoThey have to, as end-user applications can depend on those packages. My advice would be to never depend on those packages for non-system applications.
- abdullahkhalids 3y agoIts no longer recommended on Debain to use pip to install system-wide python packages. Instead * apt is used to install python packages that system packages depend on. * Users are ---required--- strongly encouraged (see below) to use virtual environments or conda to install python packages for their own usage.
- Dunedan 3y agoIt's still possible, you just need to provide the additional command line switch "--break-system-packages". When trying to install packages without, pip will even tell you that.
- yamtaddle 3y agoIt's to create a stable target for the OS. You can target "Debian [version]" and know there's some stability & consistency to the versions of various packages. There's: 1) System packages. Any OS with discrete releases should aim for stability, here, to create a useful deployment/support target. 2) User packages that the user plans to use directly. Your web browser, a spreadsheet program, maybe something like ripgrep. You don't need multiple versions, and the version you want is almost always "whatever's latest". This could also, potentially, include your main daemons on a server—SQL servers, web servers, that kind of thing. 3) Development packages. It's common to need multiple versions and to need to switch between them frequently (due to having multiple projects with the same deps at different versions, or needing to "git-bisect" or debug a branch with older deps, that kind of thing). Some overlap with 2 (especially on servers, if only because it's convenient to manage your servers' packages with the same tool you use to manage development dependencies) but they remain distinct categories. MacOS with Homebrew gives you 1 (macOS itself) and 2 (Homebrew). Some people try to use homebrew for 3, which tends to make them unhappy and leads to them making angry posts about Homebrew because doing that is a bad idea... but it's also a bad idea on most linux distros, which will be mixing together 1-3 if you try to use the system package manager for everything. You should be using something else for #3, at least. You shouldn't be using the system Go or Python packages unless you're targeting that specific distro at that specific major version as a deployment target. Linux distros tend to have difficulty separating 1 & 2, in large part, I think, because of how the graphics and multimedia stacks work. This is really annoying if you're used to having nice, clean separation between those, as on macOS + Homebrew.
- ilyt 3y agoHow does that affect you ? You're supposed to use venvs for Python (and Ruby) anyway, and for Go whatever you compile will download its own deps anyway. The libraries in distro are for distro packages. Using them is fine but by no means required.
- hello_computer 3y agoNot me directly, but a common issue on all of the Debian (& derivatives) support forums is where people bust their Python install by doing a `sudo pip install...`. I know what that does, you know what that does, but I can assure you that the average user doesn't. I mention Go because I think it's heading in the same direction on Debian-based distros. Seems like there would be a better way to keep things straight...
- diffeomorphism 3y agoLuckily python/debian recently decided to just tell you "No!" when you try that particular foot gun. https://peps.python.org/pep-0668/ https://peps.python.org/pep-0668/