5 ms·

I get it, but if you are developing on python, you should consider the "OS python" to be a completely separate thing you don't touch. The reason is that program

I get it, but if you are developing on python, you should consider the "OS python" to be a completely separate thing you don't touch. The reason is that programs in your OS are using that python, and if you muck it up, you risk damaging your OS. Updating a package could stop your computer being able to log in (although that risk is only slight). Developers should be using pyenv or similar (try Anaconda if you want "easy") and preferably one environment per project (so you can lock in library versions for the project). I'd personally prefer the "OS python" to be more hidden, but I don't know enough about linux/mac inner workings to know if thats even a thing (maybe a libpython instead?). But it is hard to understand if you aren't working with python all the time. I do basically just python, and still spent several years with outdated Ubuntu-shipped libraries before getting properly setup.

pmontra 6y ago
Agreed. The OS shipping version is not a thing in every single language I've been working with. It's either outdated or not the version my project needs, and what if I need many different versions for different projects? I always use a language manager for Elixir, Erlang, Node, PHP, Python and Ruby, either the language's usual one or asdf. I'm even using different versions of databases, usually with docker. Java is somewhat easier to deal with, unzip in a directory and set JAVA_HOME but I'm not working much with it so I could miss some nuances.
greggman3 6y ago
I would argue if not using the OS python is the correct way to do things then python by default should not install at an OS level. Installing in the OS should be left to the OS only and the default should be that python installs per project which special instructions for installing it as a default for a user and special special instructions for how to replace the OS level one. I really wish this was the default for all languages but the majority default to "install in your system" and then I run into the problems you and the OP mention. As it is, finding out/figuring out how to work around the default is always magic incantations and spells buried on page 947 of appendix G if you're lucky or else spewed around the internet in drips and drabs by unreliable and or outdated sources. As an example I wanted to contribute to some conformance tests for some browser API. The test suite used selenium which uses python all of which wanted global installs. I tried for a few hours to get it to run with local installs but I failed to find the correct secret ritual to perform and after a few hours decided I no longer felt like searching for the correct oracle to enlighten me. ps: For my particular needs a VM was not a solution
- aaronbrethorst 6y ago
  then python by default should not install at an OS level Which is exactly what will happen later this year(?): "The older Python language, version 2.7, is being deprecated in macOS 10.15 Catalina and won’t be included in macOS 10.16. The same goes for other UNIX scripting languages." https://www.macobserver.com/analysis/macos-catalina-deprecates-unix-scripting-languages/ https://www.macobserver.com/analysis/macos-catalina-deprecat... I think this is a mistake on Apple's part, fwiw.
  - toast0 6y ago
    Relying on tools that come with the system puts you in a bad place if you want to run different versions of the tools than the system provides. It's really better for everyone if the base OS contains less, and you get more from the package managee (of which there are several to choose from on MacOS). If Apple wants to provide installable tools on the OS install media, that's fine, of course.
- ldarby 6y ago
  I once shipped a python script with a dependency on the requests package, and installing that on the customer's system caused an outage on their production server with 1000s of users because of a permissions issue, that wasn't present in their and my test systems. So, no more "use the system python" for me...
  - in9 6y ago
    what a nightmare

pmontra 6y ago

Agreed. The OS shipping version is not a thing in every single language I've been working with. It's either outdated or not the version my project needs, and what if I need many different versions for different projects? I always use a language manager for Elixir, Erlang, Node, PHP, Python and Ruby, either the language's usual one or asdf. I'm even using different versions of databases, usually with docker. Java is somewhat easier to deal with, unzip in a directory and set JAVA_HOME but I'm not working much with it so I could miss some nuances.

greggman3 6y ago

I would argue if not using the OS python is the correct way to do things then python by default should not install at an OS level. Installing in the OS should be left to the OS only and the default should be that python installs per project which special instructions for installing it as a default for a user and special special instructions for how to replace the OS level one. I really wish this was the default for all languages but the majority default to "install in your system" and then I run into the problems you and the OP mention. As it is, finding out/figuring out how to work around the default is always magic incantations and spells buried on page 947 of appendix G if you're lucky or else spewed around the internet in drips and drabs by unreliable and or outdated sources. As an example I wanted to contribute to some conformance tests for some browser API. The test suite used selenium which uses python all of which wanted global installs. I tried for a few hours to get it to run with local installs but I failed to find the correct secret ritual to perform and after a few hours decided I no longer felt like searching for the correct oracle to enlighten me. ps: For my particular needs a VM was not a solution

aaronbrethorst 6y ago
then python by default should not install at an OS level Which is exactly what will happen later this year(?): "The older Python language, version 2.7, is being deprecated in macOS 10.15 Catalina and won’t be included in macOS 10.16. The same goes for other UNIX scripting languages." https://www.macobserver.com/analysis/macos-catalina-deprecates-unix-scripting-languages/ https://www.macobserver.com/analysis/macos-catalina-deprecat... I think this is a mistake on Apple's part, fwiw.
- toast0 6y ago
  Relying on tools that come with the system puts you in a bad place if you want to run different versions of the tools than the system provides. It's really better for everyone if the base OS contains less, and you get more from the package managee (of which there are several to choose from on MacOS). If Apple wants to provide installable tools on the OS install media, that's fine, of course.
ldarby 6y ago
I once shipped a python script with a dependency on the requests package, and installing that on the customer's system caused an outage on their production server with 1000s of users because of a permissions issue, that wasn't present in their and my test systems. So, no more "use the system python" for me...
- in9 6y ago
  what a nightmare