5 ms·

I'd been wondering how good pgksrc is on macOS for a little while, previously having used Homebrew wherever Nixpkgs was inconvenient or incomplete. Could pkgsrc

• nerdponx 5y ago
  I'm always interested to try different things, but I don't understand why people seem to dislike Homebrew so much. I've been a mostly-happy user on both Mac and Linux for years.
  • kelp 5y ago
    I dislike it because it’s really slow to do everything. Even printing help text is slow. Contrast with pacman on Arch, which is incredibly fast at nearly every operation. Unfortunately I’ve found all the package managers for macOS to be lacking. brew is slow, but has packages for most things and generally up to date. fink packages seem a bit out dated last I checked. At least the ones I cared about. MacPorts is also slow and somewhat out of date. pkgsrc doesn’t have Apple M1 binary packages available yet. I haven’t tried Nix. Sometimes I’m tempted to try my hand at writing my own package manager for macOS, but getting a critical mass of packaged software seems quite hard.
    • znpy 5y ago
      > pkgsrc doesn’t have Apple M1 binary packages available yet. basing this reply on my past experience with pkgsrc (in a netbsd or linux environments though) as long as you can point pkgsrc to a decent compiler and it can complete its bootstrap phase, it'll likely work.
      • kelp 5y ago
        That sounds right. But then I'm having to compile all the packages I need, which makes it even much much slower than brew when binaries are available.
        • johnklos 5y ago
          Compiling on an M1 is too slow? ;)
    • smoldesu 5y ago
      +1 for pacman. Homebrew's biggest issue is that it isn't a package manager for MacOS. You can interpret that however you want, but it's versatility is extremely limited compared to "full-fat" package managers like apt and pacman. At the end of the day, all of the MacOS package managers fit together to perform separate stop-gap solutions, where none of them really fell that great to use in the first place. Hell, pacman is so good that it's one of the core reasons I'll probably never end up fully switching my workflow to MacOS.
      • 27B28E52 5y ago
        Pacman and friends used to work on macOS (source: I compiled and used them) and maybe they still do, but when it moved to bash 4 while apple is shunning newer versions, it became too much work to build all of the prerequisites.
    • eddieh 5y ago
      Nix is probably the slowest and is missing many packages. It's Kool-Aid for the cool kids. MacPorts was good until everyone started using Homebrew. Homebrew has some weird quirks that drive me crazy, but it mostly works and is up to date. I tried pkgsrc and liked it, but a few common packages were weirdly named and it didn't have some Mac specific stuff. Some new package manager that's a mix of pkgsrc, brew, and MacPorts would be awesome. Especially if portable and could somehow also replace nvm, rbenv, pythonenv, and things of that nature.
      • pxc 5y ago
        > Nix is probably the slowest Nix evaluation can be slow sometimes, but installation is generally relatively fast, since everything in Nix is fully parallelizable. It's generally several times faster than apt, for installs that involve multiple large downloads, for example, and historically it's also faster than pacman.[1] (I think this is probably no longer the case with Pacman 6.0, which finally parallelizes downloads. In that case Nix evaluation time probably dominates.) I imagine what you're identifying as slow is searching through Nix packages. On the old/stable release of Nix, you use something like `nix-env -qaP` for this, and that requires evaluation of every package in Nix, and can take a long time. `nix search`, however, is extremely fast on the unstable releases of Nix. A Nix search using the old method is extremely slow, > 7 seconds: I  ~  time nix-env -f '<nixpkgs>' -qaP libreoffice libreoffice libreoffice-7.0.4.2 libreoffice-still libreoffice-7.0.4.2 libreoffice-still-unwrapped libreoffice-7.0.4.2 libreoffice-fresh libreoffice-7.1.2.2 libreoffice-fresh-unwrapped libreoffice-7.1.2.2 libreoffice-qt libreoffice-7.1.2.2 ________________________________________________________ Executed in 7.31 secs fish external usr time 6.79 secs 335.00 micros 6.79 secs sys time 0.52 secs 67.00 micros 0.52 secs A Nix search using the new method, which leverages cached evaluation of Nixpkgs, takes about half a second:  nix-shell -p nixUnstable --run fish  time nix search --experimental-features 'nix-command flakes' nixpkgs libreoffice <snip> * legacyPackages.x86_64-linux.libreoffice (7.0.4.2) Comprehensive, professional-quality productivity suite, a variant of openoffice.org <snip> ________________________________________________________ Executed in 576.30 millis fish external usr time 561.00 millis 252.00 micros 560.75 millis sys time 16.07 millis 55.00 micros 16.01 millis And installation, in either case, is pretty fast. It takes a few second to install, for example, Libreoffice on my system, with the vast majority of the time taken up being the download:  time nix-env -f '<nixpkgs>' -iA libreoffice installing 'libreoffice-7.0.4.2' these paths will be fetched (153.59 MiB download, 574.57 MiB unpacked): <snip> copying path '/nix/store/8yq9h91bsbgi62dhvh4xfqxvhq58b5y4-libreoffice-7.0.4.2' from 'https://cache.nixos.org'... building '/nix/store/nhmf4ak414lrzy3387kbsx8brm8hckds-user-environment.drv'... created 68 symlinks in user environment ________________________________________________________ Executed in 21.32 secs fish external usr time 1.34 secs 0.00 micros 1.34 secs sys time 0.43 secs 521.00 micros 0.42 secs (I tried for a bit to get Linuxbrew installed so I could test the same functionality with it, but Homebrew isn't portable enough to work on NixOS, since it hardcodes a ton of command and interpreter paths to files that don't exist on some distros.) — 1: https://michael.stapelberg.ch/posts/2019-08-17-linux-package-managers-are-slow/ https://michael.stapelberg.ch/posts/2019-08-17-linux-package...
    • pasc1878 5y ago
      How is macports out of date?
  • mixmastamyk 5y ago
    Built in telemetry/analytics was enough for me to not touch it with a ten foot pole.
  • mulmen 5y ago
    In addition to the valid criticisms in sibling comments: I don’t like that it changes the rules on file ownership in /opt and /usr/local. And it’s petty but I really don’t appreciate the beer brewing metaphor. It doesn’t fit and it feels forced. Giving the project a searchable name is fine but cutesy names are irritating when I have real work to do. Just name the tool and especially commands for what they do. I say this as a person who loves beer.
    • smoldesu 5y ago
      I also hate the brewing metaphors. I don't know why MacOS developers feel so compelled to abstract integral parts of your program away into unrecognizable metaphors. It's like asking for ketchup at the counter of a diner, and they insist that they only have "Heinz Tomato Sauce". Nobody in real life does this because nobody likes a smartass, so it completely escapes me why people think it's suddenly okay to do in software, particularly software designed to be used in a professional, power-user workflow.
      • mulmen 5y ago
        It's more like using a plumber analogy to make sandwiches. I mean plumbers eat lunch right? So we can refer to condiments as grout and bread and meat as tiles and pipes are the sandwiches because plumbing. Want a Reuben? That's: plumber tile rye beef-corned plumber grout saurkraut russian Also since this is in the context of making a sandwich a bunch of options to 'plumber' mention things like toaster oven wattage and temperature. set PLUMBER_PREHEAT=350 set PLUMBER_BACKEND=toaster This is all kind of a pain. Let's use pipes. Except for some reason whoever defined this uses thousand island instead of russian dressing and expects the sandwich on a plate. plumber pipe reuben --russian --to-go
        • smoldesu 5y ago
          Thanks for clearing this up. I don't make sandwiches very often, but putting it in plumbing terms made it a lot easier to digest!
  • pxc 5y ago
    It's got a larger user and contributor base on macOS than competing package managers, and that works in its favor, especially in terms of package selection. I'm not a total hater; there are people I respect who prefer Homebrew over tools that I like better for reasons I understand. And package management is a peculiar interest of mine, so I care a lot about details and there isn't any package management system that totally satisfies me. That said, every time I've used it, I've been struck by design flaws that make Homebrew feel incomplete or immature compared to most Linux system package managers. Some examples: • The last time I used it, Homebrew didn't even support recursive uninstallation of orphaned dependencies, guaranteeing the accrual of entire packages of cruft over time. This was apparently finally fixed (in the crummy way that apt-get, the worst of all the Linux system package management tools, handles it) only in 2020 [1]. • A secondary package manager taking over all of /usr/local is quite presumptous and not portable at all • Homebrew's combination of an assumption of a single-user setup with the choice of installing to global directories in the FHS is awful, and imo it's straight up deceptive to claim that Homebrew's default setup meaningfully supports ‘unprivileged package installation’ • `brew cask` is useful, but the cleavage between it and the rest of Homebrew is awkward, and it's more like an installer-fetcher à la Chocolatey than a real package management system • Homebrew's packages are built with a relatively low degree of isolation from the base system's libraries and toolchain, so it's not unusual for a macOS upgrade to break installed Homebrew packages, and the build outputs and bottles associated with a package are given per-macOS release. (To be fair, the former is a pretty common problem for all kinds of software on macOS, as well.) • I really don't like Linuxbrew's abuse of /home, which you have to stick with if you want to use bottles (binary caches) • Homebrew just doesn't support managing dependencies on libraries in some languages (e.g., Perl) at all [2]— even though it includes packages that depend on them— which fails to meet my bare minimum expectations for a general-purpose package manager. In practice, this means that you have to install additional, language-specific package managers to use Homebrew; you have to manage dependencies in them yourself; and Homebrew packages require you to install these dependencies in system-wide locations, polluting your whole operating system (a potential source of dependency hell, as well as a practical nuisance) for their sake. The latter also, of course, undercuts the unprivileged installation claim that Homebrew touts. To be fair to Homebrew, it's been a while since I used a Mac on a daily basis, and I expect that Homebrew has improved in some ways in the meantime. I know for certain that it's improved, to reiterate an example given earlier, with respect to some, if not all (i.e., not those managed externally) orphaned dependencies. And Homebrew also has some strengths, namely its very slick and orderly command-line interface. But the real reasons I try to use Homebrew as little as possible aren't about Homebrew being _bad_ so much as my preference for tools with other strengths (which require a design different from Homebrew's to implement). On macOS, I try to use Nixpkgs and nix-darwin as much as possible because I prefer things like: • declarative configuration rather than imperative state management • fully isolated builds, more predictable solutions • using a single package management tool for libraries and apps of all languages • building .apps from source like any other package • atomicity of upgrades • freedom to roll back configurations/installations at any time • ability to mix and match packages from different releases, modify dependencies for one project without affecting another • never installing language interpreters or libraries globally, except for login shells I don't really want to use anything that doesn't have those features, and for that on macOS, Nix is the only game in town. Homebrew is a pile of state to manage, and I'd rather have intentions to declare than a pile of state to manage. That issue isn't unique to Homebrew, of course. Pkgsrc doesn't share some of Homebrew's (in my view) other defects, like its abuse of the FHS on Linux, single-user design/bad permissions configuration, building many packages directly on top of macOS system libraries that change from OS release to OS release when it doesn't have to, or the expectation that library dependencies for some languages will be managed manually/externally (and in global directories, to top it off), so that's what makes Pkgsrc interesting to me as an alternative to Homebrew, even though Nix will still always be my first-line choice on macOS. — 1: https://github.com/Homebrew/brew/commit/0fa417706a2143dbec1e6fd2f29f3e3e32663252 https://github.com/Homebrew/brew/commit/0fa417706a2143dbec1e... 2: https://docs.brew.sh/Gems,-Eggs-and-Perl-Modules https://docs.brew.sh/Gems,-Eggs-and-Perl-Modules
• 1vuio0pswjnm7 5y ago
  What are the dependencies of these "next-gen" package managers. pkgsrc itself only needs C and a POSIX-like shell.
  • pxc 5y ago
    Fair question! The two that I know of currently are Nix and Guix. Both target fewer platforms than Pkgsrc, so we know right out of the gate that they're not suitable for all Pkgsrc use cases. The question of what they depend on needs fleshing out before it can be answered. Both Nix and Guix package software in a way that is, in general, hermetic. This means that they don't assume the installation of anything outside their domain— they don't require you to have anything installed on the base system to get going with them. They don't use your system's shell and they don't use your system's C library. As an exception on macOS, Nixpkgs allows some impurities for some macOS packages, e.g., they are allowed to call xcodebuild. But in general, they include their own toolchains in their entireties. So if what you're getting at is ‘where do they depend on the base system during operation’, the answer is, more or less ‘nowhere’. If the real thrust of your question is rather ‘what do you need to build them from source’, the answer, for now, in both cases is ‘a bunch of shit that they kindly prepackage for you in a binary tarball, if you want to bootstrap your own Nix or Guix on a given platform’. Guix has been doing a ton of work to reduce the size of their bootstrap seed, and it seems like within a few years they'll have it down to a hex monitor from which they can build a series of Scheme interpreters and C compilers until they have the whole system. If the main thing you're asking about is ‘what do they use internally to process their package sets’ or something like ‘what's the minimum installed size of these package managers’: for Nix/Nixpkgs you need the Nix language interpreter (written in C++), plus at least what's packaged in the ‘standard environment’ for Nixpkgs (GNU bash and coreutils, plus a libc and a C compiler which vary by platform); and for Guix you need Guile, an implementation (interpreter and runtime) of Scheme. I've never worried about their installed sizes, since they're much smaller than the total size of everything you might want to install with them. Idk the size of the full dependency closure for Guix and I don't have a great way to look it up at the moment. In the Nix case, the binary installation tarball is ~17 MB compressed and ~72 MB uncompressed, when you install it.[1] Happily, if Pkgsrc is easier to get started with due to its smaller footprint, it looks like in the future users will be able to use Pkgsrc to install Nix.[2] :) (For my part, I wouldn't mind if Nixpkgs included Pkgsrc, too. I wish it included Guix.) — 1: https://releases.nixos.org/?prefix=nix/nix-2.3.9/ https://releases.nixos.org/?prefix=nix/nix-2.3.9/ 2: https://pkgsrc.se/wip/nix https://pkgsrc.se/wip/nix
• jayp1418 5y ago
  Check this : https://pkgsrc.joyent.com/install-on-osx/ https://pkgsrc.joyent.com/install-on-osx/