7 ms·

Finally! I’m a big fan of Python, but I hope they remove ALL Python from the OS itself. I’ve spent many hours over the years messing with setups to resolve bugs

• sylens 5y ago
  100% this.
• simonw 5y ago
  https://xkcd.com/1987/ https://xkcd.com/1987/ says it all.
  • amznbyebyebye 5y ago
    That’s hillarious. It’s why I love Rstudio.. don’t have to deal with any of that as someone who is just trying to prototype and get something to work.
    • prpl 5y ago
      nobody has ever shipped R as part of the base OS
      • nurettin 5y ago
        Except Ubuntu DSVM
  • dehrmann 5y ago
    Some of this is brew-specific. The way it handles ownership isn't great.
    • bin_bash 5y ago
      I'm not sure if it resolves your ownership issues, but I am glad they went with `/opt/homebrew` in ARM Macs to at least keep homebrew in its own directory.
      • rswail 5y ago
        What they should have done from day one. The kludge they used in /usr was broken-by-design.
    • rswail 5y ago
      The way it handles ownership (or at least used to) is completely broken with screwed up stuff happening inside /usr land. Macports puts everything under /opt/local and you add /opt/local/bin to your PATH. I've never understood the preference for homebrew, when I moved to MacOS (from Linux) 5 years ago as my working development environment, I read about both and homebrew seemed like a complete kludge, whereas Macports worked the way it should. SIP just made it even more relevant. Macports deals with specific MacOS related integration (eg Java etc) using the Apple blessed mechanisms while still providing all of the flexibility of the many many packages.
• innocentoldguy 5y ago
  Apple ships with a number of utilities installed that require Python, like smtpd.py.
  • ArchOversight 5y ago
    Where does this utility exist? I can't find it on my macOS installation.
    • arihant 5y ago
      A lot (all?) has been cleared out in Monterey. I can’t find smtpd or xattr’s scripts that required the previous version. I think whatever remained before 12.3 were Automator’s py scripts. But I don’t know what scripts those were.
    • kemayo 5y ago
      Mine does seem to contain `/usr/bin/smtpd.py` with a modified date of January 22nd. It's an installation that's been updated through a number of versions of macOS, though.
      • ArchOversight 5y ago
        Ah, I see... It contains the following shebang: #!/System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python -R Which continues to work since it's a system framework.
    • deleted 5y ago
      [deleted]
    • innocentoldguy 5y ago
      I'm running Monterey on a brand new machine (no updates from older versions of macOS) and mine is in /usr/bin/.
      • ArchOversight 5y ago
• JiNCMG 5y ago
  MacOS (Certified Unix OS) is bundled with multiple OpenSource projects since it's initial OS X release, just like many other *nix OSes. It's so easy to install your own version and override it that this is not an issue. Simple response... use brew.
  • fbanon 5y ago
    >It's so easy to install your own version and override it that this is not an issue. It's easy to override it? Really? Don't forget that macOS comes with bash, zsh, ksh, tcsh... You have to override it in each of those!
    • ArchOversight 5y ago
      You can easily set your $PATH so that your preferred tooling is first in the search order.
      • deleted 5y ago
        [deleted]
      • ninkendo 5y ago
        There's a bunch of places that can still get tripped up: - scripts with `#!/usr/bin/python` instead of `#!/usr/bin/env python` - shell scripts which call /usr/bin/python directly instead of the one in your path - shell scripts which intentionally set a prefix in $PATH to some vendor directory with a custom python, but the vendoring is incomplete and leaky and it implicitly loads packages from your system python anyway plus a hojillion other things I'm not thinking of...
        • eproxus 5y ago
          GUI apps also have their own special $PATH set via launchctl.
        • tsimionescu 5y ago
          But scripts calling /usr/bin/python want to use the "system" / "bundled" Python - why would you want those to run with your version of Python???
• deeter72 5y ago
  I feel like in general Python on Mac OS is messy compared to Linux and even Windows.
  • WastingMyTime89 5y ago
    There is a lot of good things to say about Python which is a fairly nice language but I feel it is messy on every platform. Tooling makes the situation bearable nowadays but that's definitely not one of Python strong point.
• kemayo 5y ago
  My understanding is that once they remove python2, there won't be any Python bundled. There will be a python3 handler that just prints a message asking you to use `xcode-select` to install the XCode command line tools, and that'll include the actual python3... but that's a fairly up-to-date version these days. (Right now it's 3.8.9.)
• 2pEXgD0fZ5cF 5y ago
  > They really shouldn’t be bundling any Python version with the OS I fully agree, Operating Systems bundling Python and Ruby has caused me many headaches in the past and I always perceived it as a downside, never an advantage.
  • strunz 5y ago
    I mean the advantage is that you can run vanilla python on most things by default, which is how Ansible pretty much "just works".
  • wheelerof4te 5y ago
    Or rather, people should stop using newest and shiniest version of their interpreted language and stick with what most users have. Python developers also should stop introducing breaking changes to their language with every release, like it is some toy.
• derefr 5y ago
  Or at least, they shouldn't be putting it in the $PATH. Whether you're using Linux, macOS, or BSD, OS-packaged language runtimes exist for the OS itself to use, in OS-internal scripts and underpinning OS services. They shouldn't be considered "part of" the userland; as this invites userland applications to rely on them. These runtimes are actually something more like an "implementation detail" of the OS — the kind of thing whose binaries should live in $PREFIX/libexec rather than $PREFIX/bin. (Mind you, if you're a system software developer, whose software gets packaged into Operating Systems, then you do have to rely on this "implementation detail." Which often means targeting very old versions of runtimes and libraries, compared to the versions that application developers get to target.) Also, of course, there are "standard" language runtimes that should be part of the userland — e.g. /bin/sh. But these are literally standard — i.e. part of some standard like POSIX, that an OS can be tested for conformance against. Which is important, because it means that developers can write to a stable target of "POSIX compatible", assuming the existence of (and particular stable semantics of) particular standard runtimes. But none of the "modern" language runtimes are part of any such standard. The version OSes ship should be assumed to not exist. (And major third-party applications do already do the right thing, in not making any assumptions of existence, but rather installing their own vendored versions of the runtimes that they can upgrade as needed.)
  • kitsunesoba 5y ago
    I’ve always thought it strange that most Linux distributions and other *nixes don’t put up barriers between not only system and userland, but also between “essential” userland (i.e. DEs) and other user-installed packages. The lack of separation seems like a setup for failure and complicates package manager design considerably.
    • AceJohnny2 5y ago
      Can you come up with a solid definition to separate "essential" userland from other user-installed packages? You cite DEs as essential, but maybe I want to be using my own Enlightenment install rather than whatever the system has installed (true story!)
• throwaway894345 5y ago
  I fully agree with removing Python from OSes, but I don't know that it's reasonable for the average user to manage their own versions (I wish I didn't have to manage my own versions and I've been developing in Python for the last 15 years). The alternative is to ship the runtime, stdlib, and dependencies with each application, but that seems pretty sucky for an interpreted language and especially one that leans so hard on random native extensions (I've seen relatively simple applications pull in 250MB of dependencies in a compressed tarball, never mind runtime and stdlib). Really I don't think Python (and probably other interpreted languages) is a very well suited for developing end-user applications--although some people have fewer scruples than me about wasting user resources.
  • pdimitar 5y ago
    Please rest assured that this is not a flamey / troll comment, it's just that your first paragraph to me sounds like "Python is just not worth the trouble" which you kind of allude to in your second paragraph after. I mean, at what point should we start asking ourselves fundamental questions like "what is so heavenly about Python that we have to carry it everywhere and ensure its installation on every possible platform"? Example #1: I know a guy who regularly writes scripts in OCaml and laughs at everybody else, saying he gets static types and mega-fast binaries (faster than Golang and slower than Rust) and a very terse syntax (he says it's often as short or shorter than bash even). Example #2: I recently finally had enough of bash/zsh scripting weirdness for a few tasks I wanted done on my home server so I just learned enough Lua for an hour to make a fairly decent script that did exactly what I expected immediately after I understood a few of Lua's quirks (which are at least consistent and easy to remember, unlike the endless escaping and quoting rules of the scripting shells). Example #3: I know a few people using a Rust library/tool that makes scripting with it much easier and almost painless. They swear by it. -- I am not even mad at Python for potentially putting hundreds of megabytes or gigabytes of baggage on people's machines -- if we start having each app carry its own Python runtime. Meh. Many people would never care (me included). I do get ticked off by it being everywhere however; especially having in mind what an awful language for long-term projects it is (said to me by at least 5x senior Python devs at 40+ of age). And how often it messes up with other work you do on your computer, too -- which is the cherry on the cake and has been guilty of tons of broken Debian system-wide upgrades (among many others). I wish people stopped getting tempted by "easy to start with" languages and just start seeing the forest and not only the trees... :(
• cool-RR 5y ago
  Maybe just call it `system-python`.
  • anderskaseorg 5y ago
    That’s basically what RHEL does: /usr/libexec/platform-python.
• dosethree 5y ago
  When I have to install a CLI tool and it's in python I sigh loudly. Happy that many CLIs have moved or are moving to golang
  • saila 5y ago
    I use pipx for this. It isolates each tool in its own virtualenv. You might still have to install a specific Python version (although the latest 3.X works fine for me), but it takes some of the pain out of the process and makes sure you don't pollute your global/system install. On a Mac, it could be as simple as (assuming you already use Homebrew): brew install python brew install pipx pipx ensurepath # adds ~/.local/bin to $PATH pipx install <tool> <tool>
    • gullevek 5y ago
      That is all nice. And then python updates from 3.9.n to 3.9.n+1 and nothing works anymore. brew sucks with python.
      • saila 5y ago
        I've only run into issues like this when upgrading from Python 3.X to 3.Y, which is to be expected, and Homebrew lets you install a specific 3.X (e.g. brew install python@3.9) if you don't need/want be on the latest version.
    • ldrndll 5y ago
      Thanks, I didn’t know about pipx. If it works as advertised that will be a huge improvement for me!
    • oars 5y ago
      pipx looks fantastic, thanks for sharing.
    • Too 5y ago
      Pipx is really one of the best things that has happened to Python recently. Taking away all the headaches of manually managing venvs. They should integrate it into mainline imo.
• jbkiv 5y ago
  Thank you, I struggled with that problem for years. Happy that I am not the only one.
• vbezhenar 5y ago
  The only reason I'm using python is because it's available on most linuxes and macos by default. If it would be removed from macos, I'd never use it.
• stjohnswarts 5y ago
  But it's so easy to set the path up to python? I hear people complain about this all the time but I never encounter it because I'm careful and I know which interpreter I'm running ALWAYS. It really isn't a hard task to do. Having python in the OS is fine. I wish windows had a default version and I love that it's available on linux in most distros.
• tsimionescu 5y ago
  > They really shouldn’t be bundling any Python version with the OS - the user should choose the versions installed. Why? Having a bundled Python version - any version - means that you can ship Python scripts to others. Not having a Python version bundled means you can't ship Python scripts at all. Sure, you can still technically ship them, but now you need to tell users "just run this simple scipt!... after you install Python X from place Y, and now you'll have multiple Python versions installed, so here is how to keep them separate, and [...]". Or, you can bundle your script with a whole Python installation!
  • eschaton 5y ago
    It’s only really feasible to ship APIs in an end-user operating system that can make forward binary compatibility guarantees. Python doesn’t make a sufficient guarantee of forward compatibility for either scripts or its C-linkable libraries. This means that, unless an OS vendor does a bunch of extra maintenance work on the Python that they ship, an application built in or making use of the Python shipped in one version of an OS may not run on a subsequent version of that OS.
• Too 5y ago
  Having some python always installed can be nice as an advanced calculator or short ad-hoc scripts. My non tech mom needed help to wrestle a large set of semi structured data into a csv to use with Excel. On my dev machine I would have solved the problem in a minute with 5 lines of Python. On her machine, without any coding environment, I was completely stuck. Eventually figured out you can use the developer console in chrome to run some interactive Javascript and problem solved.