5 ms·

I don't really follow your logic. There are very good reasons why you wouldn't be able to install the same package in the same way on Linux and OS X. (For start

I don't really follow your logic. There are very good reasons why you wouldn't be able to install the same package in the same way on Linux and OS X. (For starters, homebrew isn't true package manager in that it's not a one-stop shop - it can't even handle critical system updates like apt-get/pacman can!) I'm arguing that we should have an OS switch in the same way we have an architecture switch. If we assume that our PM can handle application packages as well as system packages then we should also be able to use it to install application packages on any OS which support it. For example, python should be installable on everything from Windows to BSD all using the same "pm install python" command. Packages will be marked as explicitly supporting OSes. I think PKGBUILDs are the best of both worlds, because they allow system-specific package management to coexist with application-level packaging - two related, but subtly different problems. PKGBUILDs are general-purpose enough that they can do pretty much whatever you need them to do, assuming that they're well-written (which is our assumption when comparing any packaging method), and they're flexible enough that you can modify them to fit your specific system. The only real problem I see with PKGBUILDs is that, at least on Arch, they're community-developed, which means that they can be out-of-date or variable in quality. But that's no worse than the situation if you were to install from source, anyway (which is the alternative), and that's more a byproduct of the way that the Arch community is structured than the PKGBUILD system itself. I'm sure if Red Hat or Canonical suddenly decided overnight that they'd start supporting PKGBUILDs, things would be different (and would have their own problems, likely...) Agreed. Without looking, I'm 99% sure that PKGBUILDs are bash, not sh, but I'm also 99% sure that 99% of the PKGBUILDs I've ever installed are sh-compatible. And I don't think that's the worst thing in the world - in this day and age, you have to be able to handle sh for any Unix-like OS, and you have to be ready to implement the appropriate interface for any other OS that you want to be compatible (or to throw compatibility to the wind altogether, like Windows does). Second, since many PKGBUILDs are really just convenient wrappers around the already-provided application distribution mechanism, I don't see how this is that bad at all. This was my main complaint with PKGBUILDs. A bash/sh dependency hurts on non-Unix OSes. I'd rather Python than sh. I also admit that, for the most part, I absolutely hate sh and all its derivates and view them all as dirty hacks, so this is probably just innate bias.

chimeracoder 15y ago
> For example, python should be installable on everything from Windows to BSD all using the same "pm install python" command. Packages will be marked as explicitly supporting OSes. I don't see how that would work. In an abstract sense, I can conceptualize it, but from a practical standpoint, I can't see it ever being implemented well enough to the point where it would be widely adopted (which would be the whole point). If you can think of a way to do it, by all means go for it, but I just don't think it's possible. > A bash/sh dependency hurts on non-Unix OSes. I'd rather Python than sh. I also admit that, for the most part, I absolutely hate sh and all its derivates and view them all as dirty hacks, so this is probably just innate bias. I think it's just your bias. At some point, whatever language it's written in would be non-native on most of the OSes, so you'd have to port something one way or the other (Python has a fairly nice port that abstracts away some of the warts, but it's still just serving as a pseudo-agnostic interface). Given that, why not sh? It's already been ported to Windows (I've never used Cygwin, but it seems like it'd be a useful starting point), and virtually every other OS is either Unix-like or supports some native POSIX-like interface for compatibility reasons. If you're complaining about sh syntax, I'm a bit sympathetic toward that, but it's ingrained enough - and good enough - that I wouldn't go to the effort of replacing it. Also remember that, for shell scripting, you don't want a language as powerful as Python - it needs to be able to do a very small set of simple tasks and do them well. Also, just think about concurrency. We take pipes for granted, but imagine trying to do that all natively in Python.

chimeracoder 15y ago

> For example, python should be installable on everything from Windows to BSD all using the same "pm install python" command. Packages will be marked as explicitly supporting OSes. I don't see how that would work. In an abstract sense, I can conceptualize it, but from a practical standpoint, I can't see it ever being implemented well enough to the point where it would be widely adopted (which would be the whole point). If you can think of a way to do it, by all means go for it, but I just don't think it's possible. > A bash/sh dependency hurts on non-Unix OSes. I'd rather Python than sh. I also admit that, for the most part, I absolutely hate sh and all its derivates and view them all as dirty hacks, so this is probably just innate bias. I think it's just your bias. At some point, whatever language it's written in would be non-native on most of the OSes, so you'd have to port something one way or the other (Python has a fairly nice port that abstracts away some of the warts, but it's still just serving as a pseudo-agnostic interface). Given that, why not sh? It's already been ported to Windows (I've never used Cygwin, but it seems like it'd be a useful starting point), and virtually every other OS is either Unix-like or supports some native POSIX-like interface for compatibility reasons. If you're complaining about sh syntax, I'm a bit sympathetic toward that, but it's ingrained enough - and good enough - that I wouldn't go to the effort of replacing it. Also remember that, for shell scripting, you don't want a language as powerful as Python - it needs to be able to do a very small set of simple tasks and do them well. Also, just think about concurrency. We take pipes for granted, but imagine trying to do that all natively in Python.