I new to Python and to programming in general. I'm a novice, and do not work in programming, just trying to teach myself how to program as a hobby. Prior to Python, I worked with Ruby for a bit and I learned that one of the biggest challenges was actually properly setting up my computer.
Background: I'm on a Macbook with OSX 10.7.
With Ruby, you have to (or rather, you should), edit your ./profile and add PATH info. When you install and use RVM, there are additional items you need to add to your bash_profile.
Do you have to make similar changes with Python? What are the best practices as I'm installing/getting started to ensure I can install modules and packages correctly?
python works out of the box on OS X (as does ruby, for that matter). The only changes I would recommend for a beginner are:
1) Python likes to be reassured that the terminal can handle UTF-8 before it will print Unicode strings. Add export LANG=en_US.UTF-8 to .profile. (It may be that the .UTF-8 part is already present by default on Lion - I haven't checked since Snow Leopard.) Of course, this is something that will help you in debugging, but you shouldn't rely on it being set this way on other machines.
2) Install pip by doing easy_install pip (add sudo if necessary). After that, install Python packages using pip install; this way, you can easily remove them using pip uninstall.
Take a loot at Python on the Macintosh page first. Like it says, Python comes pre-installed on Mac OS X. It means that you don't have to do anything special in order to use it.
To get started, you can run a Terminal.app, type python and that will get you Python interactive shell up and running.
However, Python on OS X might be of a slightly older version. For example, OS X 10.7.3 comes with Python 2.7.1, whereas latest release version of the Python is 3.2.3. If you want to use other versions, then you will have to install them. Then it all depends on what, where and how you install. If you want to have multiple versions alongside, you may need to set some environment variables like PATH to have binaries you installed found by the bash etc. You can do it through bash ~/.profile if needed.
But until you get to that point - don't worry about it use a version shipped with OS X. Once you want a newer one - download and install it. Then, if it doesn't work out of the box or you have any other problems or concerns, feel free to ask a more specific question.
Related
Being a "normal" user (i.e. not overly familiar with code), I find myself in a bit of a python conundrum and would very much like to try to muster some kind of assistance with the following:
I use svtplay-dl and youtube-dl via homebrew in Mac OSX 10.14.6, which also requires python (among many other extensions such as ffmpeg et al). However, I now seem to have three different python versions installed, and since python3.5 is no longer supported, I thought I would delete this and make sure that homebrew/svtplay-dl/youtube-dl uses a path to python3.9.
When I type "which" followed by the following in Terminal:
python
python3.5
python3.9
...I get the following respective results:
/usr/local/bin/python
/Library/Frameworks/Python.framework/Versions/3.5/bin/python3.5
/usr/local/bin/python3.9
Based upon this short background info, can someone advise how I best uninstall/remove python3.5 and get homebrew et al to use python3.9 every time python is required?
Any help with this would be very much appreciated!
/Mark
The normal answer is to use something like virtualenv (https://virtualenv.pypa.io/en/latest/) to isolate your python environment and dependencies locally.
You need to install virtualenv on your system, then you tell it what python version to install. Once activated, any dependencies are installed and isolated in that environment. Also see: https://gist.github.com/pandafulmanda/730a9355e088a9970b18275cb9eadef3
If you want to go a step further you can use docker (https://docs.docker.com/language/python/build-images/) to isolate everything, including the operating system, in that case you don't need virtualenv, but to start with I'd play around with virtualenv.
thanks for reading this. I am using macOS High Sierra. I am not very familiar with terminal or environment variables, but am trying to learn more. From reading other threads and google, it seems like I either have multiple pythons installed, or have pythons running from different paths. However I am not able to find a solution to resolving this, either by re-pathing my IDLE or deleting it entirely.
I do have python, python launcher, and anaconda (not very sure how anaconda works, have it installed a few years back and didn't touch it) installed. I am trying to install pandas (pip install pandas), which tells me that I have it installed, but when I run it on IDLE, it says module not found. Though if i run python3 on terminal and type my code in, it works (so pandas has indeed been installed).
When i run which python on terminal, it returns
/Users/myname/anaconda3/bin/python
(when i enter into this directory from terminal, it shows that in the bin folder, I have python, python.app, python3, python3-config, python3.7, python3.7-config, python3.7m, python3.7m-config)
When i run which idle on terminal, it returns
/usr/bin/idle (im not even sure how to find this directory from the terminal)
When i run import os; print(os.path) on IDLE, it returns module 'posixpath' from '/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/posixpath.py'
Would really appreciate some help to figure out how to ensure that when i install modules from terminal, it would be installed into the same python as the one IDLE is using. Also, I would like to know whether it is possible for me to work on VSCode instead of IDLE. I cant seem to find suitable extensions for data science and its related modules (like statsmodels, pandas etc). Thanks a lot!
First of all, a quick description of anaconda:
Anaconda is meant to help you manage multiple python "environments", each one potentially having its own python version and installed packages (with their own respective versions). This is really useful in cases where you would like multiple python versions for different tasks or when there is some conflict in versions of packages, required by other ones. By default, anaconda creates a "base" environment with a specific python version, IDLE and pip. Also, anaconda provides an improved way (with respect to pip) of installing and managing packages via the command conda install <package-name>.
For the rest, I will be using the word "vanilla" to refer to the python/installation that you manually set up, independent of anaconda.
Explanation of the problem:
Now, the problem arises since you also installed python independently. The details of the problem depend on how exactly you set up both python and anaconda, so I cannot tell you exactly what went wrong. Also, I am not an OSX user, so I have no idea how python is installed and what it downloads/sets alongside.
By your description however, it seems that the "vanilla" python installation did not overwrite neither your anaconda python nor anaconda's pip, but it did install IDLE and set it up to use this new python.
So right now, when you are downloading something via pip, only the python from anaconda is able to see that and not IDLE's python.
Possible solutions:
1. Quick fix:
Just run IDLE via /Users/myname/anaconda3/bin/idle3 every time. This one uses anaconda's python and should be able to see all packages installed via conda install of pip install (*). I get this is tiresome, but you don't have to delete anything. You can also set an "alias" in your ~/.bashrc file to make the command idle specifically linking you there. Let me know with a comment if you would like me to explain how to do that, as this answer will get too long and redundant.
2. Remove conda altogether (not recommended)
You can search google on how to uninstall anaconda along with everything that it has installed. What I do not know at this point is whether your "vanilla" python will become the default, whether you will need to also manually install pip again and whether there is the need to reinstall python in order for everything to work properly.
3. Remove your python "vanilla" installation and only use anaconda
Again, I do not know how python installation works in OSX, but it should be reasonably straightforward to uninstall it. The problem now is that probably you will not have a launcher for IDLE (since I am guessing anaconda doesn't provide one on OSX) but you will be able to use it via the terminal as described in 1..
4. Last resort:
If everything fails, simply uninstall both your vanilla python (which I presume will also uninstall IDLE) and anaconda which will uninstall its own python, pip and idle versions. The relevant documentation should not be difficult to follow. Then, reinstall whichever you want anew.
Finally:
When you solve your problems, any IDE you choose, being VScode (I haven't use that either), pycharm or something else, will probably be able to integrate with your installed python. There is no need to install a new python "bundle" with every IDE.
(*): Since you said that after typing pip install pandas your anaconda's python can import pandas while IDLE cannot, I am implying in my answer that pip is also the one that comes with anaconda. You can make sure this is the case by typing which pip which should point to an anaconda directory, probably /Users/myname/anaconda3/bin/pip
First: This would be a comment if I had enough reputation.
Second: I would just delete python. Everything. And reinstall it.
To repeat and summarized what has been said on various other question answers:
1a. 3rd party packages are installed for a particular python(3).exe binary.
1b. To install multiple packages to multiple binaries, see the option from python -m pip -h.
To find out which python binary is running, execute import sys; print(sys.executable).
3a. For 3rd party package xyz usually installed in some_python/Lib/site-packages, IDLE itself has nothing to do with whether import xyz works. It only matters whether xyz is installed for 'somepython' (see 1a).
3b. To run IDLE with 'somepython', run somepython -m idlelib in a terminal or console.
somepython can be a name recognized by the OS or a path to a python executable.
I don't code but needed to use Python just for one simple task. That task specifically required a Python 2.x version. I've downloaded it from https://www.python.org/downloads/release/python-279/ and installed. Later, I wanted to remove Python, but learned that OSX has also Python 2.x preinstalled and removing it is dangerous. Is removing the one I've installed (i.e Python 2.7 package in my Applications folder) also dangerous? If not, why Finder asks me to enter my password to move those files to trash, which often required to make changes on system files?
Thanks
Removing the second Python you installed from python.org should be fine: follow the instructions at: https://docs.python.org/2.7/using/mac.html?highlight=uninstall
This Python puts itself in /Library/Frameworks/ and symlinks in /usr/local/bin/. You need admin privileges to remove things from these directories which is why it's asking for your password.
The system installation of Python is in /System/Library/Frameworks/ and /usr/bin/python. Don't mess with it because the OS needs it.
Having said that, unless you're really pressed for space, just leave things as they are and enjoy your life.
MAC OS X 10.9 (at least) and above already had python 2.7 installed, so you don't have to manually install one. Installing python and similar packages are not like what you did with your applications. So, if you are not familiar with UNIX or XNU concepts, don't remove it. It will not just remove some binaries, but also lots of library files. Asking password is because removing some library files would need higher privillege, and usually you don't have with normal account.
In a word, in your case, I suggest keep the python, and don't install new one. v2.7 is all you want.
I am looking for version (custom/beta?) of portable python that is python 3.x and includes pygame. I know pygame hasn't been fully converted to 3.x yet, but for what I need it for it works perfectly.
Install Pygame, then take your entire Python folder and put it where you want it to go.
If you mean you want to be able to use python (filename).py on the terminal, then you will have to change the PATH variable in the terminal, or add the shebang line #!usr\bin\python onto your programs.
Maybe I have not fully understood what you're after. Still, let me try to answer:
The release of Python 3.3 now includes VirtualEnv in the standard library, now called venv.
So in a command line you can type
/path/to/python3.3/bin/pyvenv /path/to/new/virtual/environment
To create a folder with links to your python 3.3 installation. That new folder makes it easy to install any PyPi packages into, for example:
cd /path/to/new/virtual/environment
./bin/pip install adventure
to install Adventure.
You then probably want to follow PyGames documentation to install the Py3 branch
Then, like user beary605 already answered you can bundle up your whole virtual environment of python by tar'ing, rsync'ing or whatever means of distribution you envision.
There's also an older question covering Python 3 and Pygame compatibility on Mac OS.
To my knowledge there is nothing like what you are looking for available, however with a little DIY you might be able to alter a version of Portable Python (it's not updated anymore, but there's a version for Python 3). By saying this I am presuming you want to operate this from a flash drive. Depending on what Windows you are running the steps might be a bit different, but I'm guessing they would be similar to the steps in this thread: pygame not working with portable python
short version: how can I get rid of the multiple-versions-of-python nightmare ?
long version: over the years, I've used several versions of python, and what is worse, several extensions to python (e.g. pygame, pylab, wxPython...). Each time it was on a different setup, with different OSes, sometimes different architectures (like my old PowerPC mac).
Nowadays I'm using a mac (OSX 10.6 on x86-64) and it's a dependency nightmare each time I want to revive script older than a few months. Python itself already comes in three different flavours in /usr/bin (2.5, 2.6, 3.1), but I had to install 2.4 from macports for pygame, something else (cannot remember what) forced me to install all three others from macports as well, so at the end of the day I'm the happy owner of seven (!) instances of python on my system.
But that's not the problem, the problem is, none of them has the right (i.e. same set of) libraries installed, some of them are 32bits, some 64bits, and now I'm pretty much lost.
For example right now I'm trying to run a three-year-old script (not written by me) which used to use matplotlib/numpy to draw a real-time plot within a rectangle of a wxwidgets window. But I'm failing miserably: py26-wxpython from macports won't install, stock python has wxwidgets included but also has some conflict between 32 bits and 64 bits, and it doesn't have numpy... what a mess !
Obviously, I'm doing things the wrong way. How do you usally cope with all that chaos ?
I solve this using virtualenv. I sympathise with wanting to avoid further layers of nightmare abstraction, but virtualenv is actually amazingly clean and simple to use. You literally do this (command line, Linux):
virtualenv my_env
This creates a new python binary and library location, and symlinks to your existing system libraries by default. Then, to switch paths to use the new environment, you do this:
source my_env/bin/activate
That's it. Now if you install modules (e.g. with easy_install), they get installed to the lib directory of the my_env directory. They don't interfere with existing libraries, you don't get weird conflicts, stuff doesn't stop working in your old environment. They're completely isolated.
To exit the environment, just do
deactivate
If you decide you made a mistake with an installation, or you don't want that environment anymore, just delete the directory:
rm -rf my_env
And you're done. It's really that simple.
virtualenv is great. ;)
Some tips:
on Mac OS X, use only the python installation in /Library/Frameworks/Python.framework.
whenever you use numpy/scipy/matplotlib, install the enthought python distribution
use virtualenv and virtualenvwrapper to keep those "system" installations pristine; ideally use one virtual environment per project, so each project's dependencies are fulfilled. And, yes, that means potentially a lot of code will be replicated in the various virtual envs.
That seems like a bigger mess indeed, but at least things work that way. Basically, if one of the projects works in a virtualenv, it will keep working no matter what upgrades you perform, since you never change the "system" installs.
Take a look at virtualenv.
What I usually do is trying to (progressively) keep up with the Python versions as they come along (and once all of the external dependencies have correct versions available).
Most of the time the Python code itself can be transferred as-is with only minor needed modifications.
My biggest Python project # work (15.000+ LOC) is now on Python 2.6 a few months (upgrading everything from Python 2.5 did take most of a day due to installing / checking 10+ dependencies...)
In general I think this is the best strategy with most of the interdependent components in the free software stack (think the dependencies in the linux software repositories): keep your versions (semi)-current (or at least: progressing at the same pace).
install the python versions you need, better if from sources
when you write a script, include the full python version into it (such as #!/usr/local/bin/python2.6)
I can't see what could go wrong.
If something does, it's probably macports fault anyway, not yours (one of the reasons I don't use macports anymore).
I know I'm probably missing something and this will get downvoted, but please leave at least a little comment in that case, thanks :)
I use the MacPorts version for everything, but as you note a lot of the default versions are bizarrely old. For example vim omnicomplete in Snow Leopard has python25 as a dependency. A lot of python related ports have old dependencies but you can usually flag the newer version at build time, for example port install vim +python26 instead of port install vim +python. Do a dry run before installing anything to see if you are pulling, for example, the whole of python24 when it isn't necessary. Check portfiles often because the naming convention as Darwin ports was getting off the ground left something to be desired. In practice I just leave everything in the default /opt... folders of MacPorts, including a copy of the entire framework with duplicates of PyObjC, etc., and just stick with one version at a time, retaining the option to return to the system default if things break unexpectedly. Which is all perhaps a bit too much work to avoid using virtualenv, which I've been meaning to get around to using.
I've had good luck using Buildout. You set up a list of which eggs and which versions you want. Buildout then downloads and installs private versions of each for you. It makes a private "python" binary with all the eggs already installed. A local "nosetests" makes things easy to debug. You can extend the build with your own functions.
On the down side, Buildout can be quite mysterious. Do "buildout -vvvv" for a while to see exactly what it's doing and why.
http://www.buildout.org/docs/tutorial.html
At least under Linux, multiple pythons can co-exist fairly happily. I use Python 2.6 on a CentOS system that needs Python 2.4 to be the default for various system things. I simply compiled and installed python 2.6 into a separate directory tree (and added the appropriate bin directory to my path) which was fairly painless. It's then invoked by typing "python2.6".
Once you have separate pythons up and running, installing libraries for a specific version is straightforward. If you invoke the setup.py script with the python you want, it will be installed in directories appropriate to that python, and scripts will be installed in the same directory as the python executable itself and will automagically use the correct python when invoked.
I also try to avoid using too many libraries. When I only need one or two functions from a library (eg scipy), I'll often see if I can just copy them to my own project.