4 ms·

I'm not sure we're talking about the same thing. Are you lamenting the difficult interface between distro package managers and language package managers? Or lam

I'm not sure we're talking about the same thing. Are you lamenting the difficult interface between distro package managers and language package managers? Or lamenting that language package managers haven't learned the lessons of previous package managers, distro and language alike? I was lamenting that Opam 1.1 wasn't dealing with a trivial package installation situation. I mentioned Debian to indicate that was the source of the version I was using, implying that there may have already been a newer version out there that I could've been using, but then explicitly saying that 1.1 should've dealt with the situation in the first place. FWIW, I definitely agree with the terrible situation of language package managers in general. I use Python sporadically, and I'm always scared of running pip. Virtualenv I'm very unhappy about because, while it definitely fulfills it's task marvelously, I think it shouldn't even have to exist in the first place! Why doesn't core Python deal with the problem itself, searching for dependencies in the main script's subdirs, the user's libdir, and lastly the system libdir? Admittedly, I don't know the intricacies of the Python ecosystem that prevent that.

e12e 12y ago
> I was lamenting that Opam 1.1 wasn't dealing with a trivial package installation situation. Well, it's all connected. A package will need a certain version of ocaml itself, it's standard-lib (or alternative) other libs it needs. These will all depend on various c libraries to a certain degree. So if opam started re-downloading a lot of dependencies that should be available, that sounds like either a) some part needed a newer version, or needed to recompile with different flags, or b) opam didn't find the dependencies installed by dpkg. Python and Debian go pretty well together, probably partly because a few core utilities use python. So with some creative use of "apt-get build-dep" you can usually get the needed c libraries that things depend on, and so have a better time installing things that need c-code in virtualenvs. I'm not sure how you think linking to (possibly rapidly moving) c-libraries from a language that runs across a wide range of operating systems and versions should work, if not with something like virtualenv (or buildout). There will, I think, always be a need for packages that are moving faster than stable distributions can/should keep up with -- and there needs to be a sane way to deal with that. With c code, you can stuff things in /usr/local -- but keeping that in sync as you patch the main os (and do dist-upgrades) and as you need to patch the various libraries/dependencies... is challenging. And that's just for c. When you put another layer on top (ruby, python etc) -- it doesn't really get any easier. One option is to go the way of bsd ports/gentoo -- but there are at least two issues/trade-offs with recompiling everything from source: 1) if you're mixing and matching versions and compile-options, you quickly end up with unique binaries. Which is to say, binaries that no-one else have tested before you. Granted any bugs you encounter will be in the program and/or the compiler -- but you'll have the joy of finding them. In production, most like. 2) It really doesn't make much sense to recompile "all the things" if the goal is to end up with the same binaries anyway.

e12e 12y ago

> I was lamenting that Opam 1.1 wasn't dealing with a trivial package installation situation. Well, it's all connected. A package will need a certain version of ocaml itself, it's standard-lib (or alternative) other libs it needs. These will all depend on various c libraries to a certain degree. So if opam started re-downloading a lot of dependencies that should be available, that sounds like either a) some part needed a newer version, or needed to recompile with different flags, or b) opam didn't find the dependencies installed by dpkg. Python and Debian go pretty well together, probably partly because a few core utilities use python. So with some creative use of "apt-get build-dep" you can usually get the needed c libraries that things depend on, and so have a better time installing things that need c-code in virtualenvs. I'm not sure how you think linking to (possibly rapidly moving) c-libraries from a language that runs across a wide range of operating systems and versions should work, if not with something like virtualenv (or buildout). There will, I think, always be a need for packages that are moving faster than stable distributions can/should keep up with -- and there needs to be a sane way to deal with that. With c code, you can stuff things in /usr/local -- but keeping that in sync as you patch the main os (and do dist-upgrades) and as you need to patch the various libraries/dependencies... is challenging. And that's just for c. When you put another layer on top (ruby, python etc) -- it doesn't really get any easier. One option is to go the way of bsd ports/gentoo -- but there are at least two issues/trade-offs with recompiling everything from source: 1) if you're mixing and matching versions and compile-options, you quickly end up with unique binaries. Which is to say, binaries that no-one else have tested before you. Granted any bugs you encounter will be in the program and/or the compiler -- but you'll have the joy of finding them. In production, most like. 2) It really doesn't make much sense to recompile "all the things" if the goal is to end up with the same binaries anyway.