I have two virtual environments. One has python 3.7.9. the other had 3.8.5. I have downloaded torch 1.6.0 in the 1st virtual env. But when trying to install the same torch version in the second virtual env, it downloads the entire package again instead of installing from cache.
Is there any way to force download from cache as I want the same torch==1.6.0 in both the environments and its frustrating to download it everytime.
Have a look at the listed files...
https://pypi.org/project/torch/#files
There are different wheels for different Python versions.
This makes sense, as eg the syntax changes between Python versions.
Related
I am running a Windows 10 machine, where I have a Python installation installed from one of the programs I am working with. This leads to dependencies of this program to specific versions of Python packages, including Jupyter and Jupyterlab, and I cannot update/upgrade them without breaking the functionality in the original program.
Hence, I decided to install a more recent version of Python in addition to the one I already have on my machine. That was also not the issue, and installing all the packages I was after went fine so far.
However, even though I installed nodejs and npm within the new version of Python, when attempting to install a widget in Jupyterlab, it still does not recognize the packages.
In addition, wen running jupyter-lab.exe --generate-config, I am getting asked, if I want to override the existing configuration file.
I have no intention to do so, but would like to be able to configure the different jupyter notebook environments separate from each other.
Is there a possibility to do so?
I am trying to create a new environment with Python 3.7 using Conda like:
conda create -n qnn python=3.7
I got following errors:
Collecting package metadata (current_repodata.json): done
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: failed
PackagesNotFoundError: The following packages are not available from current channels:
- python==3.7
Current channels:
- https://conda.anaconda.org/conda-forge/osx-arm64
- https://conda.anaconda.org/conda-forge/noarch
To search for alternate channels that may provide the conda package you're
looking for, navigate to
https://anaconda.org
and use the search bar at the top of the page.
Why is Python 3.7 apparently unavailable?
System Details
This is on an Apple Silicon (osx-arm64) machine running macOS.
No native builds available
Since Python 3.8 had been released for about a year when Apple Silicon hit the market, Python 3.7 builds for osx-arm64 were never part of the regular build matrix for Conda Forge.
Workaround: Emulate
Immediate alternatives for using 3.7 on Apple Silicon systems would be to emulate x86_64 with Rosetta or use a container system, e.g., Docker.
Creating osx-64 environments
Similar to what one does for running win-32 environments on x86_64 machines, one can create osx-64 environments like
## create empty environment
conda create -n py37
## activate
conda activate py37
## use x86_64 architecture channel(s)
conda config --env --set subdir osx-64
## install python, numpy, etc. (add more packages here...)
conda install python=3.7 numpy
⚠️ Important Note: Be sure to always activate this environment before installing packages. Otherwise, the default CONDA_SUBDIR value (osx-arm64) may be active and could result in mixing architectures in the same environment.
Note that MacOS will automatically recognize the architecture and run through Rosetta - one need not do anything special.
Requesting native build
Longer term, you could try requesting that the python-feedstock include a 3.7 build for osx-arm64. However, 3.7.12 (Sept. 2021) was technically the final feature release, and it has now entered the maintenance-only phase (see PEP 537). Also, other packages that build Python-version-specific variants would not be built for osx-arm64, so even if one had python=3.7, the packages wouldn't be there (at least not through Conda). Basically, I wouldn't bet on anyone taking this up.
Not sure if this is the best strategy, but running
CONDA_SUBDIR=osx-64 conda
worked for my use case.
Idea is to build the distroless docker image and available python3 google distorless image version is 3.7 - gcr.io/distroless/python3. Our code is already compiled and running with python3.5 version and required to upgrade the version into 3.7 so that we can get rid of the library, compactability issues and can make use of the distroless image with verison 3.7. Some questions are,
Will version upgrade cause any issues to the existing code compilation?
Do we need to change all the requirements.txt versions according to the 3.7?
If yes, will there is an impact of the application?
the Python language does not provide backward compatibility. My recommendation for you is to run your code on a virtual env with the new version of Python and test your code. If you do not want to use virtual env you could create a new docker image with the Python version and test your app. Regarding the requirements.txt, without seeing the libraries or packages there, it is impossible to say if you should change the file.
Background
I've just got a new M1 mac mini dev machine, and migrated from my old x86 mac using apple's migration assistant.
Doing that also copied over all my conda environments to the new machine (they were all in my home directory)
I installed the latest version of anaconda and anaconda plus all my python code and environments seem to work fine (this includes a bunch of wheel modules, notably numpy/scipy).
I did a bunch of googling for my questions below, but couldn't find any good answers anywhere - so I thought I'd ask SO as this seems like a quite common situation others will run into
Questions
Does anyone know the status of M1 native versions of python/numpy/scipy etc provided by conda forge?
I presume that all the binaries in my environments for python/numpy etc all still the old x86 versions, as they were all in environments in my home directory, and running via emulation. So, how do you go about changing/updating those to a M1 arm native
version if/when available?
A quick update as of July 2021.
TLDR
The conda-forge group have a M1 native conda installer here.
Installation is simple - run the installer, and you have conda up and running.
This will install an M1 native conda, and that conda's default environment will by default install M1 native python versions and M1 native versions of modules (if available).
There seem to be native osx M1 native wheels for most common modules now available on the conda-forge channel.
Current status
It seems Anaconda still do not have a native M1 version, nor does Miniconda. ...I can't figure out why it's taken so long and neither still seem to have native M1 support, but that's a separate issue.
Alternative
However, as steff above mentioned, conda-forge (as in the group responsible for maintaining the conda-forge channel) do have a installer for their version of conda that is itself both native M1, and also sets up your environment to pull M1 native wheels where available. This they call Miniforge.
Their github is here.
Various installers for their Miniforge (via direct download, curl or homebrew) can be found on their github page (above) - the direct link to the ARM native miniforge installer is here.
A quick search on conda-forge show's almost all common modules do now have native M1 wheels available. (look for supporting platform 'osx-arm64` eg numpy)
Caveats
I've not tested this too extensively yet, and I'm not sure exactly what happens if a non-M1 wheel is available (I believe it will default to downloading a no-arch version).
I'm also not sure/haven't tested whether you can mix and match M1 wheels with x86 mac wheels. (I'm guessing this would work, but haven't tried).
I also have only done minimal testing using the conda's pip, and how well it recognizes/tries to download/resolves M1 vs x86 pip packages.
The answer here is going to evolve over time, so here is the most up-to-date knowledge I have as of 27 Jan 2021.
Installing conda in emulation mode works completely fine. All you need to do is to install it in a Terminal run in emulation mode, or else install it using a Terminal emulator that has not been ported over yet.
Once your conda environments are up and running, everything else looks and feels like it did on x86 Macs.
If you'd like a bit more detail, I blogged about my experience. Hopefully it helps you here.
I got my M1 about 2 weeks ago and managed to install absolutely everything I need natively from conda-forge and pip. The installer you can download here.
As of 5Feb Homebrew is also officially supported on osx-arm64.
2022/03/02 answers
Native M1 installations are pretty simple now. Here are a few options for Miniforge and Miniconda.
(1) Using Apple's instructions for Tensorflow with Miniforge
This uses the same Miniforge solution mentioned above but includes an M1-optimized Tensorflow install, meaning TF has access to the M1 GPU cores.
Look for the "arm64: Apple Silicon" section at:
https://developer.apple.com/metal/tensorflow-plugin/
(2) Running native M1 with Miniforge and Rosetta with Miniconda side-by-side (Jeff Heaton's tutorial from 2021/11)
Jeff basically uses Apple's solution above for the native Miniforge install.
https://www.youtube.com/watch?v=w2qlou7n7MA
(3) Using native M1 Miniconda
There was a native M1 Miniconda installer published in 2021/11: Miniconda3 macOS Apple M1 64-bit bash (Py38 conda 4.10.1 2021-11-08)
https://docs.conda.io/en/latest/miniconda.html
My Experiences
I successfully ran the side-by-side installation from Jeff's tutorial with a few changes. It was very easy and I verified that in the native M1 Miniforge environment that Numpy is using the optimized BLAS/LAPACK linear algebra libraries and that Tensorflow has GPU access. I will update here after I run the Miniconda native M1 installer.
I installed the native version of python3 through miniforge (Apple version) and Spyder (Intel version) through homebrew and everything is working just fine for me with one exception, I've observed one strange behaviour when setting the "graphics backend" option to "automatic" instead of "inline".
Spyder >>> Prefernces >>> IPython Console >>> Graphics >>> Graphics Backend >>> inline, or automatic
When I start Spyder with the "inline" option and switch to "automatic", the opened kernels function just as expected. However, if I open new consoles they don't work at all. The issue also persists after restarting Spyder. The only way I manage to plot graphics in a separate window is to start Spyder with IPython console "graphics backend" set to "inline" and then change it to "automatic".
If I run python3 through terminal, plotting graphics works just fine as well.
My installation commands were:
brew install --cask miniforge
conda init zsh
conda activate
brew install --cask spyder
brew install PyQt#5
pip3 install matplotlib
You can check out this anouncement by Anaconda. You can now use Anaconda on your M1 MAC direclty.
"The 2022.05 release of Anaconda Distribution features native compiling for Apple M1’s ARM64 architecture (boasting 20% faster compute), Anaconda Navigator 2.1.4, conda 4.12.0, as well as several new and updated packages. 2022.05 is also the last release that will support win32."
In my system Python 3.8 version already install, but I want create virtual env for version 3.7 on vscode so how can I do>
To work on different environments, you can use Anaconda Prompt.
You can follow the steps given in this: https://docs.conda.io/projects/conda/en/latest/user-guide/tasks/manage-environments.html