VS Code not recognizing your Conda Environment?

It turns out that VS Code doesn't play as well with Conda environments from Anaconda or Miniconda. Refer to the following VScode docs: https://code.visualstudio.com /docs/python /environments So to create a new Conda environment that will be recognized in your VS Code, you have to specify the python version during the creation of the environment: i.e. Create a new Conda environment using the Conda installed python version 3.8.3. ~$ conda create -n <env_name> python=3.8.3 You may also have to specify the default python path in VS Code settings to make sure that it is pointing to the correct location of the python version you want to use. For instance, Mac OS comes with python 2 by default and it's location is therefore listed first in $PATH. So that is what VS Code will default to. To change this, open VS Code, click the gear icon on the bottom left of the window, and select "Settings". Alternatively you can type the shortcut "⌘," to open the settings file too. Once there, add the setting ("python.pythonPath":) and then the path to the python executable you want to use. In my case it is within my miniconda installation: /Users/username /opt/miniconda3/bin /python3.8*

Creating a new Git Repository: Master/Main issues

I had a local git repo that I needed to connect and push to a new remote repo. First, I created the new remote repo via the web interface and initialized it with a license file. Then I came back to my existing local repo, that was newly created as well with "git init", and issued the following commands: ~$ git remote add origin https://github.com/ erikamart/myrepo.git ~$ git branch -M main ~$ git push -u origin main The last push command caused the error that said there were remote changes (i.e. the new remotely made license file) that needed to be fetched and merged in first. OK, so I did--> ~$ git pull origin main Unbeknownst to me, this automatically created a new branch called "main" to pull in the remote changes while still keeping my local branch that was defaulted to be called "master". So when I tried to "git push" again, it sent 2 branches called "main" & "master" to the remote repo. In the remote web interface I was forced to complete a pull request to merge the "master" into the "main" branch and then I deleted the "master" branch since it was no longer needed. Then on my local repo, every time I tried to "git pull" to merge the changes made in the web interface, I would get the error: "Your configuration specifies to merge with the ref 'refs/heads/master' from the remote, but no such ref was fetched." This meant that even though I deleted the "master" branch, I did not locally delete the "remote-tracking branch" and reset the upstream tracking information off the now gone "master" branch. The solution ended up being to use the following commands to fix it: 1. View just remote-tracking branches --> ~$ git branch -remote >> origin/main 2. Check the local repo status and reset the tracking info --> ~$ git status ~$ git branch --unset-upstream ~$ git branch --set-upstream-to=origin/main 3. Remove obsolete local remote-tracking branches for remote branches that no longer exist --> ~$ git fetch origin --prune

Metaphor: How do you eat an elephant?

I once had a very insightful and motivating instructor that gave the best advice I've ever heard. He knew the class was getting frustrated and discouraged with the ton of information he was throwing our way. So he gave us the simplest, most comprehensible, advice I'll never forget. He said, "Think of everything you have to get done and learn as....an elephant. An elephant is a very large animal. Now pretend you have to figure out how to eat all of that elephant. How do you eat an elephant? The whole elephant. Sounds impossible, doesn't it? It's not impossible. Don't focus on the large thing in front of you and freak out, focus on tiny bits at a time and keep at it. Before you know it, you're all done. So how do you eat an elephant? A little bit at a time!"

Using SSH key passphrases

It is highly recommended to set a passphrase during the generation of an SSH key. However, this then means that you have to enter that passphrase every time you use the ssh key; UNLESS you add that key to an ssh-agent. Configure an authentication agent to handle your passphrase so you can keep it secure and don't have to enter it for each use. However, this is done differently between systems. So here's what happened to me: I generated a key + passphrase on a Linux system and didn't add it to an ssh-agent. After getting annoyed by having to use the passphrase all the time, I decided to remove it via command line. The following will decrypt the private key file and write it to a new temp file that would be used to overwrite the original encrypted private key file--> ~$ openssl rsa -in <Encrypted key filename> -out <Unencrypted key filename> ~$ mv <Unencrypted key filename> <Encrypted key filename> Months later, on a Mac OS, I generated a key + passphrase, sans ssh-agent, and got annoyed with the constant passphrase entry. So when I tried my previous solution above, I received this error: "unable to load Private Key 140736254190536:error: 0906D06C:PEM routines: PEM_read_bio:no start line: /BuildRoot/Library/ Caches/ com.apple.xbs/ Sources/libressl/ libressl-22.50.3/ libressl/ crypto/pem/ pem_lib.c:704: Expecting: ANY PRIVATE KEY". Extensive web searches to fix the issue did not help. While addressing a similarly related issue, I came across the proper way to set all this up! Thanks GitHub! Link--> https://docs.github.com/ en/free-pro-team@latest/ github/authenticating-to-github/ working-with-ssh-key-passphrases Saving a passphrase to the keychain on Mac OS--> ~$ eval "$(ssh-agent -s)" > Agent pid <some numbers> ~$ open ~/.ssh/config ~$ nano ~/.ssh/config >> Host * AddKeysToAgent yes UseKeychain yes IdentityFile ~/.ssh/<private key filename> ~$ ssh-add -K ~/.ssh/<private key filename> **************************** For Linux it's much simpler--> ~$ eval "$(ssh-agent -s)" > Agent pid <some numbers> ~$ ssh-add ~/.ssh/<private key filename>

1 2 3 4