4 ms·

Correct me if I'm wrong, but Hare doesn't say "we need no package manager" but instead "we don't need a new package manager, use the one your OS provides", at l

Correct me if I'm wrong, but Hare doesn't say "we need no package manager" but instead "we don't need a new package manager, use the one your OS provides", at least from how I understand it.

mumblemumble 5y ago
That strikes me as another C-ism that didn't deserve to be carried forward into a 21st century language. There's a reason we call it "dependency hell" and not "happy fun fussing with dependency version conflicts among projects that are completely unrelated except that you happen to be using the same computer to work on them time."
- steaminghams 5y ago
  The state of the art in package management could be considered Nix and Guix and those are both operating system level package managers and thats why they are better than npm or pypi or cargo, as the aforementioned language specific package managers _dont_ handle dependency hell as native dependencies exist. they all have the same problem as 'they work on my computer' and also encourage this ecosystem of thousands of micropackages, which in a thread so focused on security seems a little ironic given there is no way to guarantee all of those dependencies are made by good actors without a lot of vetting that just is not happening.
  - duped 5y ago
    I've never had a "works on my machine" bug when dependencies are managed per project. The only time I have ever had them is with global/os-level dependencies. And I've used cargo/npm a lot in the last few years.
  - mumblemumble 5y ago
    I do agree on the micropackages. What I keep daydreaming of is a package manager that resolves and download packages, but doesn't automatically grab transitive dependencies. I don't even want it saying, "Hey, we need to grab these 15 other ones, too, is that OK?" I don't want to hide the pain of huge dependency graphs like that; I want to feel it acutely. Give me an error message saying, "Oops I couldn't add FancyPackage because it depends on X, Y and Z transitive dependencies," and send me on a fetch quest. And I want the whole community around the language I'm working in to feel it acutely like that. That way we're all in the same boat, and collectively incentivized not to create the problem in the first place.
- wheelerof4te 5y ago
  That is on the library developers to settle out. Keeping your library API stable requires the mind of a genious and discipline of a monk. Now, keeping your language design stable and backward-compatible is a no brainer. Given that, it's possible to handle "dependency hells" simply by building from source. Hare is designed to be ultra conservative, so you don't have to worry about dependency hells. Features are in code, not builtin into the language. It is a win-win situation.
xigoi 5y ago
That's a great way to make a program work only on specific distros.
- capableweb 5y ago
  Seems it fits Hare perfectly then, as one of the explicit goals of Hare is to only support non-proprietary OSes.
  - Koshkin 5y ago
    Why? Proprietary OS have package managers.
  - xigoi 5y ago
    How is being free related to having a specific package in the package manager?
  - mumblemumble 5y ago
    I'd guess it does the opposite? If I'm writing for a proprietary OS, that's probably Windows or OS X. Both of which give me a more stable target to aim at when it comes to what dependencies I can expect. If I'm writing for an open source OS, that's probably some flavor of Linux. But which flavor? And which package manager does it use? And do they support all the dependencies I need, in the versions I need? Without pulling non-standard package repositories into the mix? When open source software has difficulty working on proprietary OSes, I think it's usually not because of the package manager. More often it's because of something like a glibc dependency. At which point the domain of support isn't really "open source OSes", it's usually something more like "glibc-based linux distributions."
- Koshkin 5y ago
  How so?
  - xigoi 5y ago
    Because you can't guarantee that every distro's package manager will have the packages you need.

Correct me if I'm wrong, but Hare doesn't say "we need no package manager" but instead "we don't need a new package manager, use the one your OS provides", at least from how I understand it.

mumblemumble 5y ago

That strikes me as another C-ism that didn't deserve to be carried forward into a 21st century language. There's a reason we call it "dependency hell" and not "happy fun fussing with dependency version conflicts among projects that are completely unrelated except that you happen to be using the same computer to work on them time."

steaminghams 5y ago
The state of the art in package management could be considered Nix and Guix and those are both operating system level package managers and thats why they are better than npm or pypi or cargo, as the aforementioned language specific package managers _dont_ handle dependency hell as native dependencies exist. they all have the same problem as 'they work on my computer' and also encourage this ecosystem of thousands of micropackages, which in a thread so focused on security seems a little ironic given there is no way to guarantee all of those dependencies are made by good actors without a lot of vetting that just is not happening.
- duped 5y ago
  I've never had a "works on my machine" bug when dependencies are managed per project. The only time I have ever had them is with global/os-level dependencies. And I've used cargo/npm a lot in the last few years.
- mumblemumble 5y ago
  I do agree on the micropackages. What I keep daydreaming of is a package manager that resolves and download packages, but doesn't automatically grab transitive dependencies. I don't even want it saying, "Hey, we need to grab these 15 other ones, too, is that OK?" I don't want to hide the pain of huge dependency graphs like that; I want to feel it acutely. Give me an error message saying, "Oops I couldn't add FancyPackage because it depends on X, Y and Z transitive dependencies," and send me on a fetch quest. And I want the whole community around the language I'm working in to feel it acutely like that. That way we're all in the same boat, and collectively incentivized not to create the problem in the first place.
wheelerof4te 5y ago
That is on the library developers to settle out. Keeping your library API stable requires the mind of a genious and discipline of a monk. Now, keeping your language design stable and backward-compatible is a no brainer. Given that, it's possible to handle "dependency hells" simply by building from source. Hare is designed to be ultra conservative, so you don't have to worry about dependency hells. Features are in code, not builtin into the language. It is a win-win situation.

xigoi 5y ago

That's a great way to make a program work only on specific distros.

capableweb 5y ago
Seems it fits Hare perfectly then, as one of the explicit goals of Hare is to only support non-proprietary OSes.
- Koshkin 5y ago
  Why? Proprietary OS have package managers.
- xigoi 5y ago
  How is being free related to having a specific package in the package manager?
- mumblemumble 5y ago
  I'd guess it does the opposite? If I'm writing for a proprietary OS, that's probably Windows or OS X. Both of which give me a more stable target to aim at when it comes to what dependencies I can expect. If I'm writing for an open source OS, that's probably some flavor of Linux. But which flavor? And which package manager does it use? And do they support all the dependencies I need, in the versions I need? Without pulling non-standard package repositories into the mix? When open source software has difficulty working on proprietary OSes, I think it's usually not because of the package manager. More often it's because of something like a glibc dependency. At which point the domain of support isn't really "open source OSes", it's usually something more like "glibc-based linux distributions."
Koshkin 5y ago
How so?
- xigoi 5y ago
  Because you can't guarantee that every distro's package manager will have the packages you need.