4 ms·

> This one might raise eyebrows, but I consider Hare’s lack of a package manager to be an important security feature Hare looks really interesting to me, and I

> This one might raise eyebrows, but I consider Hare’s lack of a package manager to be an important security feature Hare looks really interesting to me, and I want to give it a try, but this is frustrating. Whatever the author's intentions are, if there is no built-in package manager, 3rd party package managers will pop up as soon as Hare catches on. All the problems he mentions will arise in those, and any development effort to tackle those problems will be split across multiple competing package managers.

ddevault 4y ago
I sincerely hope that this does not happen, but it's a matter of shaping the culture appropriately. We explain our motivations for not having one and re-enforce that through the community and hope that this prevents people from building or adopting third-party package managers. Should the situation arise regardless, I will make some attempt to address it by defining upstream standards and perhaps blessing an implementation, but I hope very much that we won't have to. I will also point out that Hare's approach is similar to C, and no attempts to make a C package manager have caught on. It's also helped by the fact that Hare does not support proprietary operating systems IMO.
- steeleduncan 4y ago
  Its a fair point about C. Personally, I find Nix is a pretty great package manager for C, and I'd rather use that for Hare (or any other language tbh) than learn a different package manager. > Hare does not support proprietary operating systems I imagine a blessed implementation would be good here as well. Anyhow, best of luck, it really does look good. I've struggled to find "a better C" that doesn't come with downsides severe enough to tip the scales back towards C.
mamcx 4y ago
Is interesting that the package management advocated here is just the same thing, but offloaded to somebody else. The BIGGEST problem with package management is not package management, is how easy is to publish it and the lack of verification for authors. The proposed solution already use the practical solution: FRICTION and VALIDATION (by somebody else). (and lets add namespaces!) A relatively easy way to solve this: - Add namespaces by default, and LOCK the "main one". - When a solid library emerge (like for example Tokio in Rust), you give it a star or similar saying: This guys are ok. Split the package manager into 2 worlds: The walled garden and the chaos - The walled garden requiere verification with some decent amount of friction and/or reputation (like check into GitHub?) - The chaos is whatever. - Link to walled garden is ok. Link to chaos requiere a "unsafe" parameter or similar. P.D: Look like this sound like a good project to have (ie: A solid package manager manager!)
zajio1am 4y ago
Why per-language package manager is ever needed? If the dependency is dynamic library, it is already handled by OS distribution. If the dependency is compiled-in, then one can just use git to load dependencies as submodules.

ddevault 4y ago

I sincerely hope that this does not happen, but it's a matter of shaping the culture appropriately. We explain our motivations for not having one and re-enforce that through the community and hope that this prevents people from building or adopting third-party package managers. Should the situation arise regardless, I will make some attempt to address it by defining upstream standards and perhaps blessing an implementation, but I hope very much that we won't have to. I will also point out that Hare's approach is similar to C, and no attempts to make a C package manager have caught on. It's also helped by the fact that Hare does not support proprietary operating systems IMO.

steeleduncan 4y ago
Its a fair point about C. Personally, I find Nix is a pretty great package manager for C, and I'd rather use that for Hare (or any other language tbh) than learn a different package manager. > Hare does not support proprietary operating systems I imagine a blessed implementation would be good here as well. Anyhow, best of luck, it really does look good. I've struggled to find "a better C" that doesn't come with downsides severe enough to tip the scales back towards C.

mamcx 4y ago

Is interesting that the package management advocated here is just the same thing, but offloaded to somebody else. The BIGGEST problem with package management is not package management, is how easy is to publish it and the lack of verification for authors. The proposed solution already use the practical solution: FRICTION and VALIDATION (by somebody else). (and lets add namespaces!) A relatively easy way to solve this: - Add namespaces by default, and LOCK the "main one". - When a solid library emerge (like for example Tokio in Rust), you give it a star or similar saying: This guys are ok. Split the package manager into 2 worlds: The walled garden and the chaos - The walled garden requiere verification with some decent amount of friction and/or reputation (like check into GitHub?) - The chaos is whatever. - Link to walled garden is ok. Link to chaos requiere a "unsafe" parameter or similar. P.D: Look like this sound like a good project to have (ie: A solid package manager manager!)

zajio1am 4y ago

Why per-language package manager is ever needed? If the dependency is dynamic library, it is already handled by OS distribution. If the dependency is compiled-in, then one can just use git to load dependencies as submodules.