[DividableMiddle]

This has been a topic brought up internally at Apple many times over the past decade. Glad to see it finally moving forward. Although I see the benefits to having a system-version of these packages.. if you're doing anything serious for production then the environment should be containerized.

[Waterluvian]

Python and pip just being there is a huge advantage for newbies. I really think that part of programming is constantly ignored because all the decision-makers are not newbies.

[dcosson]

It's honestly terrible for newbies. If they try to use it, there's no pip included. So then they easy_install all their libraries which installs things into different places than most python devs will be used to. Or they easy_install pip first. But even still, everything is installing to system paths, so when they try to install things it fails with permission errors. They find a stack overflow post that says just "sudo" everything and they go to town. And there's no way to reset anything when it gets borked either because it's the system install.

Compare that to "brew install python". Now you have the most up to date version, with the right permissions for your user, that you can always brew uninstall and reinstall later if you need a different version or a clean install.

[adrianN]

So you're saying Apple should adopt brew as default package manager and install all system tools using brew? I could get behind that, but just dropping everything without replacement makes it harder for first-time programmers.

[Fnoord]

That, with analytics off by default. Also, Homebrew depends on Ruby, and Apple just ditched that

[ch4s3]

Homebrew installs it’s own ruby when necessary.

[wyclif]

you can always brew uninstall and reinstall later if you need a different version

That is the wrong way to do it. Just install pyenv/pipenv to manage different Python versions. It's dead simple to maintain system Python, Python 2.7x, and Python3.7.3 that way.

[dcosson]

Yes but I’ve never seen someone new to programming that bothered trying to figure out pyenv or similar. Even a lot of moderately experienced devs don’t bother with it. I guess it’s hard to realize the benefits of keeping environments organized until you’ve been burned by it.

[willio58]

Wrong way? I’ve used this method successfully for years.

[wyclif]

Sure you can do that, but why would you want to install and re-install different versions of Python depending on what you needed at the moment? Pyenv manages all that nicely. You can have 2x and 3x side by side without having to reinstall and uninstall anything.

[Sean1708]

> You can have 2x and 3x side by side without having to reinstall and uninstall anything.

You can do that anyway, `python` is always Python 2 (except on Arch where `python` is Python 3 and the Python 2 executable is `python2`) and the Python 3 executable is called `python3`. `pyenv` is more for keeping multiple minor versions of the same major version (e.g. Python 3.6 and Python 3.7) around at the same time.

[xapata]

Or conda, which I prefer to pipenv + pyenv.

[toyg]

Homebrew is not perfect though - it doesn't handle multi-versions (e.g. 3.7 and 3.8 running in parallel), which were working fine with Apple's Framework mechanism. Pyenv is superior in that respect (although it's fundamentally a hack). But I agree that brew does a better job for newbies than Apple's system python.

[AlexeyBrin]

AFAIK, macOS comes with Python 2.7 and without pip. For any serious, modern, Python development you need to install Python 3 yourself.

[Waterluvian]

Again the word "serious" is there telling me people are absolutely aloof to the kinds of new developers there are and what it's like to be a non programmer.

[AlexeyBrin]

What newbie will start with Python 2.7 at this point in time? Most books and tutorials are updated for Python 3. The default Python 2.7 interpreter from macOS is useless for newbies, it does more harm than good by confusing them.

[Wowfunhappy]

Apple could solve this problem by including python3 with macOS...

[Twisell]

They sure could, but is it worthy to maintain an alternative package and deployment system for which you have no use yourself? Will employees be careful and committed to something useless for their jobs?

They previously deprecated Java runtime for similar reasons. And I can’t really blame them, roadmap is crystal clear now, they prefer to assign ressources to develop Swift/Swift UI and improve tooling for native code development.

[IshKebab]

Presumably someone said that about python 2 back in the day and that turned out to be a pretty bad decision.

[c256]

Apple could solve this problems by including homebrew with macOS...

[kccqzy]

The young, bored but smart kid in an elementary or middle school tinkering with her computer and finding something to do. She doesn't need a book or a tutorial to tell her the "right" way. She experiments, only guided by her curiosity.

[em500]

There still Swift Playground, Safari JS console, not to mention old fashioned zsh/bash/ksh to tinker with. The part where the removal of the default macOS Python/Ruby/perl (which don't even have autocompletion) kills her curiosity seems far fetched.

[wyclif]

The point is that Python 2.7x is being EOL'd now. The Python that person will likely encounter in the very near future will be Python3.

[AmericanChopper]

Why would a new programmer want to start with a deprecated language?

[TheOtherHobbes]

Because they don't know it's a deprecated language.

In fact they probably don't even know what "deprecated" means.

It wasn't that long ago that Python 2.7 was the default on the Raspberry Pi. (That may still be true - I haven't checked recently.)

There's a huge ecosystem of Python 2.7 tutorials, introductions, and sample code out there. Very little of it is prefaced with "Of course you should use Python 3 now."

[AmericanChopper]

I bet they know how versions work though, and that 3.7 is higher than 2.7. I just googled ‘Python tutorial’ and only one of the results on the first page was for python 2. The first result was ‘The Python Tutorial — Python 3.7.3 documentation’. If some non-programmer was going to start learning python, they’re most likely going to start with google. I can’t see them digging deeper into the results because they want to learn an older version of the language.

[x0x0]

otoh, helping people start by just typing python is great!

otoh, pointing people towards messing with system python... well, it's a trap. And they will get burned, and it will be a nightmare to straighten out.

[lapnitnelav]

Yeah you'd be better off having a proper clean install of Python + virtualenvwrapper as your starting point.

[benatkin]

Not true. It's better for them to install it themselves so they know exactly what they're using, and so they type python for python 3 and not python3.

[Bonooru]

I'm gonna disagree on this one. When you're just starting, the installation process can be nontrivial and the terminal window is scary. Having less friction there makes it easier to start and build some confidence. Once you have some idea of what you're doing, you can realize that you want different versions of the language.

[daveFNbuck]

I think this is a better argument for Apple providing a package manager with the operating system so that installing python is as easy as typing "brew install python3". Then it'll be just as easy for newbies to learn less standard languages.

[IshKebab]

What's more scary? Copying and pasting two lines into the terminal, or working out why the hell pip doesn't work.

[banachtarski]

If you have a tough time installing software that has maybe a dozen words or so of instructions in a clear easy-to-read format... you really have no business learning to code until you learn how to use your computer first.

[erik_seaberg]

Always ask for python2 or python3. "#!/usr/bin/env python" probably won't ever be able to detect and run both, so no matter what you wanted there will always be systems on which you won't get it.

[loktarogar]

no. it's better for newbies to learn programming rather than fight with operating systems trying to set up an environment to learn programming in

[benatkin]

If you follow a python 3 tutorial when your computer has python 2 installed on it, that's a terribly annoying way of fighting with your tools. I've seen it happen. I'd rather they don't risk it and just start fresh.

[sametmax]

Not only pip is not provided, but virtualenv neither.

The alternatuve to the current decision is for apple to assign people to keep updating python and provide previous versions as packages like linux distrib does. But it has never been the way they do business.

[arvinsim]

Learning how to install Python and Pip should be part of the learning process for newbies.

[Bjartr]

Learning how to install and configure development environments is an important skill in general, but I'm not convinced having those skills as a prerequisite for exploring programming as a newbie is at all valuable.

[benatkin]

It is valuable if they start out with python 3 instead of python 2.

[Bjartr]

I'd say that depends on what kind of newbie we're talking about.

[drak0n1c]

On macOS the best config-free entry to programming is Swift and Swift Playgrounds. Everything else can have config and shell hell for further more advanced learning purposes.

[saagarjha]

You still have to download Xcode, of course.

[SeanLuke]

I'm sure that my kids will certainly love to hear that they have to learn Unix in order to learn a build system in order to try out Python. It's all part of the "learning process for newbies."

[saghm]

> learn Unix in order to learn a build system in order to try out Python

I definitely understand that the installation process for things like python can be confusing to non-programmers, but I think this is a bit disingenuous. You don't have to learn a build system to install it; python was the first programming language I ever learned, and I used it years before I ever even had any idea what a build system is.

[photojosh]

Good grief. What's wrong with going to www.python.org/downloads/ and clicking the big button at the top that says "Download the latest version for Mac OS X"?

If you can't even download an installer and run it, then yeah, maybe not quite ready for programming either.

Please forgive my snark, but this would be exactly my thought process as a reasonably competent computer user who wanted to learn Python.

[jasonkester]

He’s right though.

When I was six years old, learning to program involved turning on the computer and typing

  10 print “hello”
  run

That’s what I want for my kids. And there’s nothing even remotely like it in today’s world.

[em500]

Open Terminal

    $ echo "hello"

seems pretty much the same to me.

Even on Windows you can open the browser console and do

    > console.log("hello")

Just for teaching basic prints, variables, loops and functions, terminal bash on macOS/Linux or Javascript console work just as well as Commodore 64 BASIC.

The problem is not that the environment is not available or setup is too difficult. The problem is that there's now way more competition from other shinies readily available (web, apps, games, videos). Even if you boot your home PC straight into a terminal, as soon as the kids find the way to a web browser it's game over. Even on 1980s home micros, if the kids got access to (pirated) games, practically none would volunterily keep on programming BASIC.

[Fnoord]

When you were 6 years old is a different time from now. You probably did not have an always-on connection. There was probably no such thing as Web 2.0. Computers were more difficult to use. Google did not exist. The Internet was perhaps still taking off...

[skocznymroczny]

And then I remember that there wasn't much more to offer, because most "fun" functionality involved POKE'ing 'random' memory addresses.

[bshipp]

Installing the version you need when you want to run a script is arguably easier for newbies than all the error messages arising from an out of date implementation originally included with an OS.

it's not like installing python is any more complicated than any other piece of software that needs to be installed. Windows users have had no choice but to do that for decades.

[SeanLuke]

> Windows users have had no choice but to do that for decades.

You're saying this like it's a good thing.

[bshipp]

It's not a good thing or a bad thing. I'm saying it's not a thing at all.

If someone decides they want to run a custom ruby or python script the least difficult aspect of that decision is installing the interpreter. For example, I was dealing with someone yesterday who decided they wanted to learn how to write apps for Android. Without even seeing a single line of code (or even knowing which language they would have to learn!!) they had already successfully installed Android Studio and Jetbrains IDEA.

Without coming across as some gatekeeping greybeard, I think anyone who has even a glancing interest in programming would agree if you can't follow a one-line/click installation instruction you may want to find a simpler tool for the task than writing your own code from scratch.

[Godel_unicode]

Lots of people on just this thread, who have far more than a glancing interest, have expressed their disagreement with this exact idea.

The hardest part for lots of people in learning to program is getting over the idea that programming is for Special People, or possibly Wizards, who know lots of incantations which are beyond mere mortals. Please stop trying to convince them they're right.

Source: I've taught lots of marketing people, admins, call center techs, etc to program in PowerShell or system Python.

[rurban]

The problem is not doing anything serious. Of course this would need an updated language runtime.

The problem is doing something simple, like an installer. bash => zsh: fine. You can still install with the old /bin/bash. but for many cases a shell is not enough, and then you have to compile something statically for a trivial dynamic task. Which makes the download 10x larger. Not cool.

[tlrobinson]

It seems like there’s an opportunity for a lightweight statically-linked scripting language. Something between Go and Python.

[rurban]

The standard toolkit for this is perl. It's used in automake, most gnu utils and git. python and ruby bring nothing new to the table, besides being newbie friendlier.

[erikpukinskis]

> if you're doing anything serious for production then the environment should be containerized.

What do you mean?

[__full_pint]

I’m not OP but:

When you build and package things for production you should create an environment. This ensures the packaging the right versioning of requirements for build.

Say you build using the system version but use packages based on another version. It may work for you but probably won’t work elsewhere.

[erikpukinskis]

But you wouldn’t want to develop in that environment, right? You do integration testing in it, but development should largely happen in small modules, with unit tests and test data, no?

[__full_pint]

Of course you do that type of testing.

The problem comes about when someone does the following:

- creates python project

- pip install some_package

- import some_package

Turns out some package was already in the path but a different version

- proceeds to test and build with the assumption of some_package @ newer

- all tests pass

- ships project with requirements of some_package @ newer

Someone attempts to use the package but it doesn’t work.

[erikpukinskis]

Right, that’s why you do integration testing (manual and automated) but are you saying therefore you should do all development inside a production environment?

That’s what doesn’t pass muster to me. Why should I work on my CSS styles in an environment with the production database? It will be much slower than just working on that package in my desktop environment with just enough scaffolding the code runs.

But maybe I’m not understanding your suggestion.

[__full_pint]

OP was referring to containerizing your environment for package development.

What does connecting to a production DB have to do with any of that?

[ynx]

at the very least, virtualenv (for Python) to isolate the library dependencies from the system libraries.

[new_realist]

Does OSX offer reasonable container technology? chroot?

[pram]

macOS has a native hypervisor framework, Docker and xhyve uses it.

https://developer.apple.com/documentation/hypervisor https://github.com/moby/hyperkit

[new_realist]

A hypervisor is not exactly a container. Definitely not in the Linux sense. It may be more secure, but it is also slower.

Further, there's no decent solution for shipping a macOS container image to run in a VM. Linux, yes, Mac, no.

Finally, good luck getting your virtualized macOS app to interact reasonably with your main OS (no drag and drop, no OpenGL, etc.).

I would rather chroot.

[markstos]

How much slower?

[jackfraser]

Not much slower than, say, Hyper-V or Virtualbox or other hypervisors that live alongside a general purpose desktop OS. Remember, they're using the same Intel chips and VT-d and such as anything else; as long as you have enough CPU power it's going to run fine.

IIRC the Docker implementation for OS X runs a tiny, carefully-configured Linux VM transparently in the background. This isn't that dissimilar from the Windows Subsystem for Linux from a user standpoint.

I've done plenty of Docker work on OS X; the only real weirdness is that you're running Linux in the containers and OS X outside. Eventually, though, before switching completely to a native Linux desktop, I moved deeper into the containers and would barely ever see the OS X command prompt any more.

[tele_ski]

Our build time on Linux container is 8 minutes, but it's a few hours on macOS using docker containers. I haven't dug into it but the hypervisor seems to be single threading the normally multicore compile.

[wyufro]

Primarily disk access is a lot slower, even with Hyper-V. Eg. Compilation suffers from this. But tasks that don't use the disk too much shouldn't be that bad.

[TehCorwiz]

Measurably slower than a LXC container, but still much faster than a full VM.

[bpye]

Qemu has a backend too if I'm not mistaken?

[AceJohnny2]

In other words, nothing serious.

Does anyone actually use Docker on Mac?

Xhyve is more of a proof-of-concept than a production-ready tool.

[RussianCow]

> Does anyone actually use Docker on Mac?

What? We use it at work every day for local development, and my previous employer did as well. It has issues, definitely, but they have more to do with Docker than with xhyve.

[enneff]

But doesn’t Docker on Mac run a Linux VM? I don’t think it uses any of MacOS’s isolation features.

[frizkie]

It uses Hyperkit: https://github.com/moby/hyperkit

[dwaite]

> Does anyone actually use Docker on Mac?

I use it extensively. It is a desktop product however; it you aren't expected to put a swarm of MacBook pros into production.

[brianwawok]

Unless you want to run CD to the App Store? So fun....

[jackfraser]

Ah, but if the XServe had not died and datacenters had racks of these things, there'd no doubt be a production quality implementation by now. Shame.

[jen20]

Xhyve is but one of the options for fronting hypervisor.framework.

Calling it “not serious” is quite wrong.

[abhorrence]

I use Docker on Mac, and know many others who do as well.

[markn951]

I personally know of at least 3 or 4 engineering teams of 30+ developers who use it daily.

[konart]

>Does anyone actually use Docker on Mac?

Sure, for development tasks.

[m463]

I think apple fundamentally does not understand containers.

All the interesting container stuff is on other platforms.

It might be out of fear, maybe because apple doesn't want macos to be virtualized.

It would be really nice to have say the current xcode in one container and a dev xcode in another. It would be nice to farm work out to a lot of machines.

or a dockerfile like: FROM macos:10.14

RUN installer xcode... RUN xcode-build myproject

[eropple]

> I think apple fundamentally does not understand containers.

Given that Apple is (or at least was) one of the biggest users of Mesos in the world and have invited me to interview specifically on the back of the operationalization of containers, I'm guessing that the staggeringly bright programmers they've got probably understand containers.

Just a little hunch, you know?

[m463]

The devops guys need to spread the love to the OS group and ship it with the OS.

Maybe it's another "you're not the target market" kind of thing.

The point I'm getting at is that folks on other platforms have lots and lots of options and apple doesn't provide any.

[saagarjha]

> apple doesn't want macos to be virtualized.

The macOS EULA explicitly allows macOS to be virtualized if you do it on a Mac running macOS.

> It would be really nice to have say the current xcode in one container and a dev xcode in another.

This is the entire point behind xcode-select. I currently have Xcode-beta and Xcode on side-by-side on my machine, and they pretty much coexist.

[eropple]

Can you run them simultaneously? I've never tried.

[plorkyeran]

Yes, but there are some issues. For pure macOS development it's usually fine, but anything touching the simulator breaks if multiple versions of Xcode try to use it at the same time. I quickly got in the habit of always exiting Xcode before starting a different version.

[m463]

- "allows" not the same as supports.

- I think xcode-select just modifies a .plist.

[saagarjha]

It changes a symlink at /var/db/xcode_select_link, and all of the development tool stubs that Apple has placed consult this to see which binary to run. This is pretty much the officially supported way to switch between multiple copies of Xcode.

[toyg]

Containers lose a lot of appeal once you leave the server, and Apple have explicitly abandoned the server market.

They do offer a set of "primitives" for virtualization, which can be hooked into by third-party solutions like Docker if they want to do so.

[Gaelan]

I imagine you could get pretty far with sandboxing+chroot, but it wouldn’t be docker. You’d definitely be able to prevent stuff in the container from getting out, but I’m not so sure you could reproduce docker’s “VM-like” (I.e. the inside of the container is ~identical to a normal Linux machine, with no need to make stuff compatible) quality.

[wedn3sday]

Singularity recently released a (non-fully featured, but still useful) mac version.