4 ms·
> I pretty strongly disagree here. > The fact of the matter is just that tonnes of bugs, incompatibilities, permission problems, and bad installation experienc
by cycomanic 3y ago
> I pretty strongly disagree here.
> The fact of the matter is just that tonnes of bugs, incompatibilities, permission problems, and bad installation experiences every Linux user is intimately familiar with, often occur because package code has no control over which versions or whatever of system-level dependencies like Xorg, Fontconfi, Cairo, etc. are already installed.
I can tell you I had orders of magnitude more issues with inferior (and I have yet to encounter one which is anywhere close to a system package manager) language package managers. The main issue that one might encounter (especially with super stable packages like Cairo or fontconfig), is that the package one wants to install uses some feature of the most cutting edge release and the system has an older release.
The consideration of not always using the latest and greatest and considering only stable releases seems to have completely gone missing and people just argue to install everything via virtual environments or docker containers. So we end up with tons of different versions of the same library all over the place.
Regarding Julia being not public facing and security being not an issue, that someone else mentioned somewhere else down the thread, this package builds interactive dashboards. That's pretty public facing to me.
- patagurbon 3y agoIt's fairly easy, if not super user friendly, to opt out of the Julia-vendored binaries though. If you've ever tried to install CUDA related packages from a poorly configured Python environment you'll have encountered this issue. On the vast majority of machines if you want to use CUDA.jl you just add it as a dependency. There's a reason much of Julia's audience uses things like Spack or even static dependencies in their non-Julia code. If you just want to get work done fussing with PATH issues or the right version of CMake/gcc/LLVM-OMP etc etc can take hours. Once you've gotten the work done, and you know it will load on most users computers, you're ready to deploy. Then just add an Overrides.toml to your environment. From the other side, just like websites there is a barrier caused by "please install W, X, Y, Z dependencies" vs "Pkg.add("GLMakie")"
- bmitc 3y agoThis seems much more like a critique of Linux than any language or package development. And Linux is particularly a nightmare when it comes to graphical things.
- cycomanic 3y agoActually I would argue the reason that every language is inventing their own poor package manager, is because other OS don't have proper package management. As I said in the previous post, I hardly ever have issues with my system packages. Helping people set up an environment to develop cython code for windows on the other hand is an absolute nightmare.
- adgjlsfhk1 3y agoHave you used Julia's package manager? Imo, it works better than apt and snap (I don't have enough experience with RPM/flatpack to compare)
- bmitc 3y agoI would say most language package managers I have used are easier than than any Linux package manager I have used.