5 ms·

We really need to port Homebrew to Windows so that projects like this can be the base, but people can pull in packages on top of it, like a lightweight Cygwin b

We really need to port Homebrew to Windows so that projects like this can be the base, but people can pull in packages on top of it, like a lightweight Cygwin but more Windows'y.

tikhonj 15y ago
Does porting Homebrew make any more sense than porting something from Linux (for example)? My impression is that the Mac OS ones aren't as good. A package manager really sounds like the sort of project where the incompatibilities between *nix and Windows are large enough that writing a new one would make more sense. I think there are even existing projects like that for Windows; I remember seeing one on HN a while back, but can't recall the name.
- natesm 15y ago
  The advantage of Homebrew is that it is modern, small, and simple. Obviously apt is better, but apt also requires that you maintain a large repository of binaries. Homebrew is slow[1], but because it builds from source it is trivial to create a new package. Homebrew packages are just Ruby files. If the project uses Autotools, all you generally need to do is enter the URL, an md5, and the dependencies, then it Just Works. If it uses waf or something it's still just a simple modification. Instead of reinventing its own selfupdate functionality, Homebrew just uses git. Updating Homebrew is really just fast forwarding a git repository. Finally, the maintainers explicitly do not duplicate the libraries/tools that ship with OS X. This is a big step up on OS X from Macports, which installs itself in /opt/local and rebuilds everything possible. Homebrew is instantly understandable. Packages are files, you just match them by name. apt is admittedly more complex, but at least you get something for that complexity. [1] really what's slow is building from source. Homebrew itself is very fast.
  - nupark2 15y ago
    Everything you just said (packages are files, simple, uses existing tools for self update) applies to MacPorts too. The only real differences seem to be the use of Ruby, and an attempt to avoid replacing OS dependencies -- even if the replacements are newer. In fact, MacPorts actually supports generating Debian packages and an apt repository straight from its port files. As for Windows, Cygwin already provides binaries. An apt repository of them would be great. I'm not convinced porting homebrew or MacPorts makes sense, however -- they're both fairly Mac-focused.
    - chalst 15y ago
      Macports builds something of a sandbox, which from the users point of view is neither small nor simple. It is easier for the Macports team to make sense of bug reports with a sandbox, however, which is, I assume, why they do it. It is explicitly the reason they forbid installing to /usr/local.
      - saurik 15y ago
        Macports used to not build this "sandbox", but learned the lesson that relying on Apple as your only source of updates to critical base libraries was fraught with peril: not only do you not get updates you might need ("upgrade to 10.6" is not a reasonable response to someone who just wants to use a project that needs a slightly newer version of libcurl), but sometimes Apple can ship changes that break compatibility without realizing it (as they were not using that part of the library). Once you start dealing with this complexity, the sandbox is actually much /simpler/, as you get well defined results: the only variability are changes in kernel behavior, which tend to be a much less shifty target.
        chalst 15y ago
        The "sandbox" increases the complexity of the system that the user deals with. The other notion of simplicity is one that should matter only to the Macports developers. I do not like to criticise open-source projects, but the (reasonably polite) hostility that stating this simple fact has attracted does make me think that the supporters of Macports have stopped seeing things from the user's point of view. If you want a packaging system whose job is to protect you from the risk of certain rare but possibly messy mishaps, then Macports might well be what you want. I recommend being less risk averse, and use a mixture of Homebrew and installing to /usr/local. It will cost some research and reinstall time now and then, but it will result in a system that is easier to get an overview on. The talk I have seen of "destroying" one's system installing via Homebrew is pure FUD, and I do not know what lies behind it.
        saurik 15y ago
- baronfel 15y ago
  Are you perhaps thinking about the CoApp project? It's making some decent progess, check out CoApp.org for updates. Last I heard they were in the process of shallow-forking a slew of OSS projects and building them natively in Windows.
Niten 15y ago
pkgsrc already supports Windows Services for Unix, it may well work on top of this too (though I haven't looked at Gow yet and I honestly have no idea how it differs from MSYS). But when I think "Unix-like core plus package management on Windows"... well, Cygwin is already there.
- 4ad 15y ago
  SFU/SUA only work on enterprise/ultimate versions of Windows. Also, pkgsrc is reported to work, but who actually tries it know it works pretty bad and it requires lots of manual patching.
xer0 15y ago
https://code.google.com/p/apt-cyg/ https://code.google.com/p/apt-cyg/ "apt-cyg is a command-line installer for Cygwin which cooperates with Cygwin Setup and uses the same repository. The syntax is similar to apt-get. Usage examples:" "apt-cyg install <package names>" to install packages "apt-cyg remove <package names>" to remove packages "apt-cyg update" to update setup.ini "apt-cyg show" to show installed packages "apt-cyg find <pattern(s)>" to find packages matching patterns "apt-cyg describe <pattern(s)>" to describe packages matching patterns "apt-cyg packageof <commands or files>" to locate parent packages

We really need to port Homebrew to Windows so that projects like this can be the base, but people can pull in packages on top of it, like a lightweight Cygwin but more Windows'y.

tikhonj 15y ago

Does porting Homebrew make any more sense than porting something from Linux (for example)? My impression is that the Mac OS ones aren't as good. A package manager really sounds like the sort of project where the incompatibilities between *nix and Windows are large enough that writing a new one would make more sense. I think there are even existing projects like that for Windows; I remember seeing one on HN a while back, but can't recall the name.

natesm 15y ago
The advantage of Homebrew is that it is modern, small, and simple. Obviously apt is better, but apt also requires that you maintain a large repository of binaries. Homebrew is slow[1], but because it builds from source it is trivial to create a new package. Homebrew packages are just Ruby files. If the project uses Autotools, all you generally need to do is enter the URL, an md5, and the dependencies, then it Just Works. If it uses waf or something it's still just a simple modification. Instead of reinventing its own selfupdate functionality, Homebrew just uses git. Updating Homebrew is really just fast forwarding a git repository. Finally, the maintainers explicitly do not duplicate the libraries/tools that ship with OS X. This is a big step up on OS X from Macports, which installs itself in /opt/local and rebuilds everything possible. Homebrew is instantly understandable. Packages are files, you just match them by name. apt is admittedly more complex, but at least you get something for that complexity. [1] really what's slow is building from source. Homebrew itself is very fast.
- nupark2 15y ago
  Everything you just said (packages are files, simple, uses existing tools for self update) applies to MacPorts too. The only real differences seem to be the use of Ruby, and an attempt to avoid replacing OS dependencies -- even if the replacements are newer. In fact, MacPorts actually supports generating Debian packages and an apt repository straight from its port files. As for Windows, Cygwin already provides binaries. An apt repository of them would be great. I'm not convinced porting homebrew or MacPorts makes sense, however -- they're both fairly Mac-focused.
  - chalst 15y ago
    Macports builds something of a sandbox, which from the users point of view is neither small nor simple. It is easier for the Macports team to make sense of bug reports with a sandbox, however, which is, I assume, why they do it. It is explicitly the reason they forbid installing to /usr/local.
    - saurik 15y ago
      Macports used to not build this "sandbox", but learned the lesson that relying on Apple as your only source of updates to critical base libraries was fraught with peril: not only do you not get updates you might need ("upgrade to 10.6" is not a reasonable response to someone who just wants to use a project that needs a slightly newer version of libcurl), but sometimes Apple can ship changes that break compatibility without realizing it (as they were not using that part of the library). Once you start dealing with this complexity, the sandbox is actually much /simpler/, as you get well defined results: the only variability are changes in kernel behavior, which tend to be a much less shifty target.
      - chalst 15y ago
        The "sandbox" increases the complexity of the system that the user deals with. The other notion of simplicity is one that should matter only to the Macports developers. I do not like to criticise open-source projects, but the (reasonably polite) hostility that stating this simple fact has attracted does make me think that the supporters of Macports have stopped seeing things from the user's point of view. If you want a packaging system whose job is to protect you from the risk of certain rare but possibly messy mishaps, then Macports might well be what you want. I recommend being less risk averse, and use a mixture of Homebrew and installing to /usr/local. It will cost some research and reinstall time now and then, but it will result in a system that is easier to get an overview on. The talk I have seen of "destroying" one's system installing via Homebrew is pure FUD, and I do not know what lies behind it.
        saurik 15y ago
baronfel 15y ago
Are you perhaps thinking about the CoApp project? It's making some decent progess, check out CoApp.org for updates. Last I heard they were in the process of shallow-forking a slew of OSS projects and building them natively in Windows.

Niten 15y ago

pkgsrc already supports Windows Services for Unix, it may well work on top of this too (though I haven't looked at Gow yet and I honestly have no idea how it differs from MSYS). But when I think "Unix-like core plus package management on Windows"... well, Cygwin is already there.

4ad 15y ago
SFU/SUA only work on enterprise/ultimate versions of Windows. Also, pkgsrc is reported to work, but who actually tries it know it works pretty bad and it requires lots of manual patching.

xer0 15y ago

https://code.google.com/p/apt-cyg/ https://code.google.com/p/apt-cyg/ "apt-cyg is a command-line installer for Cygwin which cooperates with Cygwin Setup and uses the same repository. The syntax is similar to apt-get. Usage examples:" "apt-cyg install <package names>" to install packages "apt-cyg remove <package names>" to remove packages "apt-cyg update" to update setup.ini "apt-cyg show" to show installed packages "apt-cyg find <pattern(s)>" to find packages matching patterns "apt-cyg describe <pattern(s)>" to describe packages matching patterns "apt-cyg packageof <commands or files>" to locate parent packages