From Newsgroup: comp.lang.python
Let me try to answer this properly, instead of "simply".
The "problematic" part of your question is "with my Anaconda
distribution". Anaconda distribution comes with the conda program that
manages installed packages. A single Anaconda distribution may have
multiple NumPy versions installed at the same time, although only one
will be available to the Python process (note that this means that sub-processes created in this Python process won't necessarily have
the same version of NumPy!). To make matters worse, it's common for
Anaconda users to use pip to install packages.
Now, Anaconda has a concept of virtual environments independent of
Python's venv module. In order to create such environments it can be
configured to either link (usually hard-link) installed packages into
the dedicated directory, or to copy these packages into the said
directory. This will become important once you inevitably ask the
follow-up question: "why do I have this version of NumPy?".
Unfortunately, you also need to consider setuptools. The traditional
setup.py install command may install multiple versions of the same
package into the same directory. Even worse, "pip install -e", the
glorified "setup.py develop", complicates things even further by
adding the "installed" package to the pth file, which can, again,
create ambiguities as to the resolution of the package location.
On top of this, there's an environment variable: PYTHONPATH that can
be set to add an arbitrary number of source directories for Python to
look up package location.
So, suppose you ran:
python -c "import numpy; numpy.__version__"
and then ran a Jupyter notebook and discovered that the version of
NumPy in that notebook is not the one you just saw in the previous
output... What went wrong?
You then may try:
conda info numpy
and get yet another answer. And then you run
pip show numpy
And the answer is still different!
Of course, it's not necessary that all these answers are different.
And, in most circumstances they are going to be consistent... but they
don't have to be!
Below is the list of typical problems I encountered in my attempts to
resolve similar problems for Python users. Of course, this list is not exhaustive.
1. If the version in the Jupyter notebook differs from the one in the environment in which the Jupyter server was started, you need to look
for the Jupyter kernel definition. There are many ways in which the
Jupyter kernel definition may alter the module lookup locations, but
the most common one is that using Python from the active virtual
environment isn't the default for the default Jupyter kernel.
2. If installed modules in conda environments are hard-linked, and at
some point pip or setuptools were used to install extra packages, you
might have "botched" unrelated environments by overwriting files
through hard-links without you even knowing that.
3. conda will happily install outdated versions of conda into virtual environments it creates. The format of conda virtual environments
changed over time, and older versions of conda are unaware of the new
format, while newer versions are unaware of the old format. If you
happen to run the conda command from the wrong environment you may get unexpected results (especially if both the new and the old version of
conda have created environments with the same name!) To avoid this,
you'd want to deactivate all conda environments activated so far until
you are at least in the base environment.
4. Usually, some diagnostic information can be gleaned from printing
the value of PYTHONPATH environment variable, sys.paths list (inside
Python), sys.sysconfig.get_path('platlib') (and looking into this
directory for duplicate packages with different version or for the pth
files.) If you discover anomalies, try to figure out if you had to use
pip to install packages (this may indirectly mean using setuptools).
Similarly, running "conda build" may indirectly result in running
setuptools commands. Also, some popular tools like to do bad things to
packages and virtual environments: pytest and tox come to mind. pytest
can manipulate module lookup locations (and you will need to dissect
its configuration to figure this out). tox, afaik, is unaware of conda
virtual environments, and will try to create venv-style virtual
environments, which will have all the same problems as using pip in
conda environments does.
5. Final warning: no matter how ridiculous this is: the current
directory in Python is added to the module lookup path, and it
*precedes* every other lookup location. If, accidentally, you placed a
numpy.py in the current directory of your Python process -- that is
going to be the numpy module you import. To make this even worse,
this behavior used to depend on whether you start Python with PDB
active or not (with PDB, the current working directory wasn't added to
the path, and module imports resolved differently). I'm not quite sure
which version of Python fixed that.
On Wed, May 15, 2024 at 9:10 PM MRAB via Python-list
<
[email protected]> wrote:
On 2024-05-15 19:42, Popov, Dmitry Yu via Python-list wrote:
What would be the easiest way to learn which version of NumPy I have with my Anaconda distribution?
Import numpy and print its '__version__' attribute.
--
https://mail.python.org/mailman/listinfo/python-list
--- Synchronet 3.20a-Linux NewsLink 1.114