Thanks. That confirms some of my surmises. I may still have the
Anaconda version on one of my notebook computers. I may use that to
write and debug source code, since I like the Spyder IDE, and then
copy working programs to my main desktop computer to run them in
Windows with no virtual environment.
On Sat, Nov 3, 2018 at 7:39 AM Mats Wichmann <m...@wichmann.us> wrote:
>
> On 11/2/18 10:01 PM, Roger B. Atkins wrote:
> > Okay, but what about the virtual environments? Once the Windows 10
> > path environment variable has a version of Python added to it, Windows
> > will find it (I am using Win 10), but will it be found from within any
> > given virtual environment (venv), regardless of which version created
> > the environment? And if 3rd party packages have been installed within
> > a venv, will they be found a) by Windows, and b) by the Python version
> > within the venv, even if it was not used to install the packages?
>
> (a) when you activate a virtualenv, it will always find that python (the
> one the env was created from), that's what the activation does - fiddle
> paths so you see that envirnoment and not any other that may be sitting
> around.
>
> (b) when you pip install with a virtualenv active the installation will
> be private to that virtualenv.
>
> which leads to... Anaconda uses virtualenvs (afiak, _always_, rather
> than "when you ask for one" like many IDEs do), so, packages installed
> though Anaconda are in that sense "private". They're not secret - you
> can see them all in the physical location where the virtualenv is set
> up, if you figure out where that is.
>
> > These questions confounded me until I finally deleted Anaconda, and
> > Python with it, because when running programs in Windows vice the
> > Spyder IDE, Windows could find Python, but not the 3rd party packages
> > such as pyperclip, bs4, and requests. I suspect it had something to do
> > with the Anaconda installation process establishing a venv, and the
> > package locations not existing (or not being visible) in Windows.
> I don't think developers of projects like Anaconda expect that their
> target users will try to run Python lots of different ways, so getting
> things all under their control is helpful and presents a consistent
> front, which is really the value the project brings - you want to do
> some (for example) scientific work in Python, and some notes tell you
> you need to install these 17 packages, and if you're on Windows, a
> couple of them maybe don't work because you don't have a C compiler
> installed - Anaconda puts that all in once place and makes it easier.
> Doesn't mean it isn't still occasionally confusing. If you need to run
> more versions, you can always install pkgs a second time, "outside" the
> Anaconda world. It should even be quick to do, pip caches packages it
> has downloaded so it probably won't even need to re-download.
>
>
> p.s. Python can tell you which Python it is running:
>
> $ python
> Python 2.7.15 (default, Oct 15 2018, 15:24:06)
> [GCC 8.1.1 20180712 (Red Hat 8.1.1-5)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys
> >>> sys.executable
> '/usr/bin/python'
> >>>
> $ source ~/virtualenv/py2/bin/activate
> $ python
> Python 2.7.15 (default, Oct 15 2018, 15:24:06)
> [GCC 8.1.1 20180712 (Red Hat 8.1.1-5)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys
> >>> sys.executable
> '/home/mats/virtualenv/py2/bin/python'
> >>>
>
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
