Develop Reference

How do I use Virtual Environments with SublimeREPL?

I am a beginner to coding in general and I just found out that we could create virtual environments and was soon disappointed to see that there was no tutorial or answer anywhere for a Windows user and the only one I found was THIS. Which kinda solves my problem but isn't ideal. And I wanted to follow forms that actually SOLVED my problem but they were for mac and linux users. So can someone help me out?
Thanks in advance !!!

It is mentioned in the docs:
For virtualenv created environments to be discoverable by SublimeREPL
they should be created or symlinked in one of the following:
~/.virtualenvs default for virtualenvwrapper
~/.venvs default for venv
Alternatively, more paths can be added to “python_virtualenv_paths” in
the SublimeREPL configuration file.
If your virtualenvs are created in another directory add them to SublimeREPL.sublime-settings. For me, they are in ~/Envs:
{
"python_virtualenv_paths": ["C:\\Users\\my_username\\Envs"]
}
Assuming you're using the correct path, sublimeREPL: Python - virtualenv allows you to select the venv you want to work with:

Conflicts between multiple versions of conda

I use miniconda to manage my python environments on Windows 10. Additionally, I use software called ESRI ArcGIS Pro that comes bundled with it's own versions of conda and python that are somewhat modified to work with their software. I must use ESRI's conda to manage environments that interact with this application.
I have this same set up on both my laptop and desktop, and until recently had no issues. However, recently ESRI's conda stopped working on my laptop. Any conda commands (e.g. conda list, conda info --envs, conda create -n myenv, even just conda by itself) produce no output whatsoever. At first I suspected that PATH was set incorrectly, but I've check that this is not the case (even calling ERIS's conda.exe with a full path still does not work). I then suspected that the conda.exe file itself was corrupted, but this also is not the case (copied it to my desktop and it works fine there).
I suspect it may have something to do with my separate miniconda installation. It doesn't seem to be an issue of environmental variables being set incorrectly (again checked against the working system), but I'm wondering if there is any possibility that there are Registry entries (perhaps set by my Miniconda install) that could be causing this issue?
Any thoughts on why this might be the case? Or advice on how to proceed with diagnosing the issue?
EDIT:
Per merv's request, my conda environmental variables:
CONDA_DEFAULT_ENV=C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3
CONDA_PREFIX=C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3
CONDA_PS1_BACKUP=$P$G
Clearly these paths are different than normal due to the custom distribution.
To answer your other questions, no other conda commands generate any output whatsoever. As for activate I don't have any other environments to try activating (the arcgispro-py3 env you see above is the name of the 'base' env that ships with the software), but deactivate seems to work. Another slight difference to mention is that conda activate ... is not a command in this special conda, you have to just use activate by itself which AFAICT calls a shell script.

Should a virtualenv have it's own "argparse"?

I have a virtual environment, that's used by multiple people on multiple machines. I ran into a problem today that a user couldn't import argparse.
The problem ended up being that I am running python2.7.10_2 and he is running 2.7.13. The python in the virtualenv, is mine, so 2.7.10_2. This meant that it was looking for system libraries in the wrong place (/usr/local/Cellar/python/2.7.10_2, instead of 2.7.13/) However, I thought that the point of virtual environments is that all of the libraries are in the venv, and so it doesn't matter what versions of python you actually have installed anywhere.
However, it seems that there is no argparse in venv/lib/site-packages, and so it uses my original PYTHONPATH, which isn't correct for the user.
For other reasons, the virtualenv was originally created with the relocatable flag, so that isn't the problem.
ETA:
The solution I came up with (hideous kludge though it is) Is that I had the user symlink 2.7.13 to 2.7.10_2, so it can find his original libraries.

How to change the interpreter of the project

I created a django project and its interpreter is an 3.5.2 ENV, all the extensions that I install in Pycharm it doesn't recognize them, when I try to add them in Installed APPS, they aren't available.
But if the interpreter is only python.exe it recognizes.
So, How do I change the intrepeter of a project that is set to the 3.5 2 ENV to another, I don't know exatly what ENV is, and why it doesn't allow me to use installed extensions.

Go to preferences then project. You can set the interpreter there.

I assume the ENV you are talking about is a virtual environment. You normally create your project inside a virtual environment in order to maintain project-specific dependencies. E.g. If you install a dependency in your virtual environment, it can be accessed ONLY from that container. So, it is not installed system-wide and therefore cannot be accessed by things outside of the ENV.
Makes sense because you don't really want to install project specific things system-wide. E.g. what if you wanted to work on one project with Django 1.10 and another with 1.8? You would create two virtualenvs to encapsulate each!
I know it doesn't answer your main question but it may help to understand what's going on.
https://virtualenv.pypa.io/en/stable/

System Python conflict between Anaconda and existing Python installation

I've been going with a basic Python3.4 install that I've been installing many modules into for over the past month but have reached a point where pip is coming up short and I'm going to just install the full Anaconda on my system to go deeper into bokeh-server stuff.
I get a popup during the Windows 64bit installer (Anaconda3-2.3.0-Windows-x86_64.exe) saying
A version of Python 3.4 (64-bit) is already at C:\Python34\ We
recommend that if you want Anaconda registered as your system Python,
you unregister this Python first. If you really know this is what you
want, click OK, otherwise click cancel to continue.
Didn't find much documentation on this subject, and I'm not really sure how to "unregister" that installation of Python apart from uninstalling it entirely from Windows which I imagine would accomplish such a thing. Is this basically telling me to check how my Python Launcher for Windows is setup after the Anaconda installation? I'm completely unfamiliar with this notion of python system registration? Is that just a round about warning about which python version takes precedence on the system path, or which installation holds the file associations?

The solution is simply to uninstall python (for example, run the original python installer and select the uninstall option). The python key in the windows registry will be removed (which is what unregister means in this context).

Here is a link to a script that will unregister a Python installation (if you haven't come across it already). I personally have not dealt with anything like this. It seems like it should work, but you may have to tinker around with some of the paths in the script to get things to work. The links in #nightuser 's post will also probably fix the issue.
Why not just remove your version of Python? You could do a pip freeze > requirements.txt with your current Python and add them to Anaconda, or create an environment with Anaconda using those packages. Anaconda has greatly decreased the amount of time I spend setting things up.

You are getting that prompt because you have another version already installed the safe way to do this is going to the directory of the existing version and running the uninstaller. Once the previous version is completely uninstalled. You can run the installation as normal it should works!

enter image description hereYou have already installed python in your environment, so your system can handle your python code. Anaconda can handle your python code as well. If you install Anaconda and expect use python provided by Anaconda, then your system will confuse about assigning the code job. To avoid this confusion, there is always a path to point out which python you want.
You can ask your OS to find specific python by changing your environment path in windows OS:
By deleting the python path your Python will be invisible. Changing path is more convenient compared with the uninstall.
If you got a python compiling software like Pycharm, things are different. Pycharm may have python3.6 while your system got python 3.5. You need to delete path in those software or uninstall python specified by those software.
Pycharm
Actually, instead of registering the Anaconda as the system python, you can install it first, then specify your Pycharm and system path to the Anaconda python path. Thus, your Pycharm will use python provided by Anaconda and package & virtual environment you need.
I edit this for lots of times because I got Great wall, so I can't close something pop up in my screen(cause it is Blank). And everything is missing if I refresh. This is annoying.
My system path Anaconda3's python36
Add path in Pycharm
Or you can't use these packages and Anacon's virtual Environment