![]() ![]() PROTIP: Various methods of installing Python are incompatible with each other. For example, both Django 1.3 and Django 1.0 the web application development framework for Python need to be maintained at the same time. This has given rise to several versions of Python frameworks being maintained in parallel. Some Python functions in one version do not work with commands in another version. There are two separate versions of Python: 2 and 3. The version of Python that comes with Apple MacOS is obsolete and needs to be updated along with Apple XCode CLI for the MacOS version you’re using. I’ve pulled out the various incantations suggested by others on StackOverlowĪnd put them here in context. “PROTIP:” here highlight information I haven’t seen elsewhere on the internetīecause it is hard-won, little-know but significant factsīased on my personal research and experience. Not intended to represent any employer (past or present). NOTE: Content here are my personal opinions, and Here I’m taking a “deep dive” approach because I haven’t seen one on the internet. Uninstall Python and Python packages within various package managers. ![]() This tutorial describes the different options to install and Install pip homebrew without setuptools.Or, whatever works in that version of Python. So, if you are actually going to work with multiple versions of Python enough to warrant it: do a separate checkout of Python source code for each version you want to work with. so, if after building Python 3.7 you switched to Python 3.8, the headers will be wrong for this package. Then, this package will ask the current Python to point at the header files it was built with, and it will point to your Git repository, and whatever current version of headers are in that repository. the problem will appear when you need to install a Python package with native code that's distributed in the source form. venv to get the environment with that version. Then, whenever you create a virtual environment, you'd do python3.7 -m venv. When you compile and then do make altinstall you get the Python you want installed in the same prefix, but called something like /usr/bin/python3.7. It's only when you try to step out of line and do something more complex than the absolute trivial thing you get to learn about the downsides. The problem with all those things, however, is that if your use case is very simple, all of them seem to kinda work. It both critically depends on setuptools and fights them tooth and nail. CMake is thus a sworn enemy of Conda, for example. Conda is in a state of permanent war with other build tools it installs, because from Conda's perspective those tools don't work correctly, and it's trying to "fix" them. Conda tries to be not only the package manager for Python, but also to manage the installation a lof of other stuff too, like compilers, build tools, native libraries, and so on. If Pyenv can fail in X ways, Conda can fail in X X ways. It's the worst tool you can possibly have in terms of predictability, your ability to understand what's going on with your setup, etc. If Pyenv is a horrid mess, Conda brings this mess to a whole new level. Everything will be easily discoverable, in predictable places, no collisions with the system's Python, for the most part. The best way to go, if you want multiple versions of Python, thus, IMO is to git clone them, checkout the version you want, build it with the C compiler of your system, and do make altinstall. Python's own virtual environments are lame, but, at least they are very predictably lame. At least because it doesn't add a lot of complexity to your process, and it's relatively easy to troubleshoot the problems. Just downloading the binaries / source from and running them may actually be not such a bad idea. but, it's a proprietary jail you are in, and there's no preventing your system from doing things you don't want, so, that project is doomed to fail. Maybe if you are very careful, and you make sure to install everything through brew, and prevent your system from doing things you didn't want. You wanted to have a C compiler installed through Brew? Apple thinks XCode knows better what compiler you need etc. It's not properly integrated with the rest of MacOS, and people at Apple will screw it over every chance they get, because they don't care. On its own, it's a vipers nets of problems, combined with other programs it creates situations where you'd be wondering for weeks around your workstation trying to figure out what went wrong, and you still wouldn't know. This is a bad project that greatly complicates things, especially, if you have problems with integration with other tools that need Python. As someone who has to deal with problems other people create by trying to install various versions of Python and helper programs, here's what I came to believe so far: Pyenvĭitch it as fast as you can.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |