3 ms·

vscode example notwithstanding, I do not encounter the 'conflicting packages' problem very often on Arch. In fact, I don't remember the last time I encountered

vscode example notwithstanding, I do not encounter the 'conflicting packages' problem very often on Arch. In fact, I don't remember the last time I encountered it, other than when it's an explicit choice - like, Python can only have one version of a package installed for the system Python interpreter, so if you try to install both python-numpy and python-numpy-mkl-bin, well, you have to choose. That's how Python works, though you can of course make additional Python environments (venv/conda/whatever) with different packages. I notice the vscode example involves the AUR, which is not the official repositories. I consider that a broken package, and it should be fixed. One of the packages should rename its main executable or whatever. Chrome, for example, has various versions, but they ship binaries with different names, e.g. /usr/bin/google-chrome-stable. The great thing about Arch is that there is one canonical user repository, the AUR. So the official repos should not have conflicts unless absolutely necessary, and the AUR should endeavour not to have conflicts, though it's more of a wild-west so they're somewhat more likely. However, you generally don't have to think about how to not conflict with whatever random packages may be out there - you only need to consider the repos and the AUR. Anyone making their own packages that are not in the official repos or the AUR, and yet conflict with them, well, that's their problem. Arch being super up to date and the existence of the AUR really does obviate the need for containerising apps to a large degree, at least from the perspective of ensuring dependencies are satisfied (there are still security reasons to want containerisation). I don't believe I have any containerised apps, and yet I'm running loads of modern common programs like zoom, chrome, discord, spotify, the list goes on.

tempay 4y ago
> if you try to install both python-numpy and python-numpy-mkl-bin, well, you have to choose. That's how Python works It's possible to have as many Python versions as you like installed at the same time. All of the libraries and headers include the major/minor version, packages are installed in `lib/pythonX.Y` and the Python binary itself is available as `pythonX.Y`. Few distributions support this well for anything other than a single 2.x and 3.x but it's nothing to do with how Python itself works.
- doubleunplussed 4y ago
  That's for different Python interpreters altogether, you still can't have multiple numpy packages in any one of them. Arch actually supports multiple Pythons just fine, I currently have a bunch of 3.x Python interpreters I installed from the AUR. But installing other Python packages with these interpreters indeed needs to be done outside the system's package manager, e.g. with pip -U or a venv (usually a venv for me).

tempay 4y ago

> if you try to install both python-numpy and python-numpy-mkl-bin, well, you have to choose. That's how Python works It's possible to have as many Python versions as you like installed at the same time. All of the libraries and headers include the major/minor version, packages are installed in `lib/pythonX.Y` and the Python binary itself is available as `pythonX.Y`. Few distributions support this well for anything other than a single 2.x and 3.x but it's nothing to do with how Python itself works.

doubleunplussed 4y ago
That's for different Python interpreters altogether, you still can't have multiple numpy packages in any one of them. Arch actually supports multiple Pythons just fine, I currently have a bunch of 3.x Python interpreters I installed from the AUR. But installing other Python packages with these interpreters indeed needs to be done outside the system's package manager, e.g. with pip -U or a venv (usually a venv for me).